3 ms·

"unless there is an absolute need to break" So when someone has to decide between language X and Y, with the risk of another Python 2.x to 3.x "drama", that ar

"unless there is an absolute need to break" So when someone has to decide between language X and Y, with the risk of another Python 2.x to 3.x "drama", that argument would be an important point for picking one language or another. For long term decisions "predictions" are a risk, i.e. not committing in backwards compatibility. Commitment reduces the risk. I asked for commitment not because of "purity" but because of the risk. P.S. I like Python. What I don't like is the 2.x to 3.x transition, and the risk of happening a similar thing again.

yeukhon 9y ago
In some cases, if they have to break it, they have to break it. CPython developers are notorious for writing PEP and takes so many iterations, debate till end of the world, in order for the developers to accept and publish a PEP. While I do not speak for any of them, what the blog post is trying to say is they have made a mistake with the 2 to 3 transition by introducing so many breaking changes. Instead, they have acknowledged this mistake, and will work very hard to not break anymore. But they also want to reserve a tiny room so they are not called "you lied to us!" Perhaps some fundamental change has to be made. If there is one person who hates breakage, it will be Linus. See http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html He made it clear that over the years, there has been very few exceptions allowed. On the contrary, he mentioned that kernel internal APIs are fine to break. What we want to achieve in general, according to Linus, is avoid breaking user APIs (or userland in Linux). But rest assure, when some new language feature added, or changed, or broken in CPython, you can expect a PEP. Lastly, you still have the option to send the devs (including Guido) an angry email on python-dev :-) The devs are users themselves, so I am sure they are sympathetic with the pains in the 2-to-3 transition.
- faragon 9y ago
  "The devs are users themselves, and they hate breaking changes too." Sure. That's the point: e.g. back in the day UTF-8 was invented for allowing Unicode support without breaking API compatibility. I ask for thinking 10.000 times before breaking backwards compatibility.

yeukhon 9y ago

In some cases, if they have to break it, they have to break it. CPython developers are notorious for writing PEP and takes so many iterations, debate till end of the world, in order for the developers to accept and publish a PEP. While I do not speak for any of them, what the blog post is trying to say is they have made a mistake with the 2 to 3 transition by introducing so many breaking changes. Instead, they have acknowledged this mistake, and will work very hard to not break anymore. But they also want to reserve a tiny room so they are not called "you lied to us!" Perhaps some fundamental change has to be made. If there is one person who hates breakage, it will be Linus. See http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html He made it clear that over the years, there has been very few exceptions allowed. On the contrary, he mentioned that kernel internal APIs are fine to break. What we want to achieve in general, according to Linus, is avoid breaking user APIs (or userland in Linux). But rest assure, when some new language feature added, or changed, or broken in CPython, you can expect a PEP. Lastly, you still have the option to send the devs (including Guido) an angry email on python-dev :-) The devs are users themselves, so I am sure they are sympathetic with the pains in the 2-to-3 transition.

faragon 9y ago
"The devs are users themselves, and they hate breaking changes too." Sure. That's the point: e.g. back in the day UTF-8 was invented for allowing Unicode support without breaking API compatibility. I ask for thinking 10.000 times before breaking backwards compatibility.