8 ms·

If there is Python 4, please, make it backwards compatible. Thank you.

by faragon 9y ago

eropple 9y ago
A major version bump does tend to imply breaking changes.
- faragon 9y ago
  Why?
  - eropple 9y ago
    What exactly does the term "major version update" mean to you if not for a break in backwards compatibility? That's what a major version update is.
    - faragon 9y ago
      How many mainstream programming languages do you know having equivalent issues as Python 2.x to 3.x? Do you think it is reasonable to rewrite your code base on every programming language "major version update"? One thing is deprecation of features, because of not thinking an API properly back in the day, and another, involving an important rewrite in order to get your code base working. My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
  - majewsky 9y ago
    Because that's what distinguishes major versions from minor versions (at least traditionally). https://en.wikipedia.org/wiki/Software_versioning#Change_significance https://en.wikipedia.org/wiki/Software_versioning#Change_sig...
yeukhon 9y ago
http://www.curiousefficiency.org/posts/2014/08/python-4000.html http://www.curiousefficiency.org/posts/2014/08/python-4000.h... It will be backward compatible (unless there is an absolute need to break), but just keep Python 4 out of your head. For now, they predict just 3.10+
- faragon 9y ago
  "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.

If there is Python 4, please, make it backwards compatible. Thank you.

eropple 9y ago

A major version bump does tend to imply breaking changes.

faragon 9y ago
Why?
- eropple 9y ago
  What exactly does the term "major version update" mean to you if not for a break in backwards compatibility? That's what a major version update is.
  - faragon 9y ago
    How many mainstream programming languages do you know having equivalent issues as Python 2.x to 3.x? Do you think it is reasonable to rewrite your code base on every programming language "major version update"? One thing is deprecation of features, because of not thinking an API properly back in the day, and another, involving an important rewrite in order to get your code base working. My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
- majewsky 9y ago
  Because that's what distinguishes major versions from minor versions (at least traditionally). https://en.wikipedia.org/wiki/Software_versioning#Change_significance https://en.wikipedia.org/wiki/Software_versioning#Change_sig...

yeukhon 9y ago

http://www.curiousefficiency.org/posts/2014/08/python-4000.html http://www.curiousefficiency.org/posts/2014/08/python-4000.h... It will be backward compatible (unless there is an absolute need to break), but just keep Python 4 out of your head. For now, they predict just 3.10+

faragon 9y ago
"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.