7 ms·

Python 4.0 doesn’t mean anything. Python 3.0 made breaking changes from 2.7. I think any reasonable person can agree that what was done and how it was done was

by cletus 5y ago

Python 4.0 doesn’t mean anything. Python 3.0 made breaking changes from 2.7. I think any reasonable person can agree that what was done and how it was done was a mistake. Specifically, some people decided that since X was already being broken, there’s no reason not to also break Y and Z. That happened in 2008 and we’re still dealing with it. My go to example is the string prefix qualifier. Python 2.x defaulted to byte strings. You could use Unicode strings with the u prefix. Byte strings could be specified with the s prefix. Python 3 went all in on Unicode. Unfortunately these prefixes weren’t legal in 3.0. This was just a nightmare for library writers who wanted to support both. And it was completely unnecessary. This was such an own goal that some later minor version added them back. So there’s really no meaning to Python 4.0 because minor versions no longer guarantee there are no breaking changes. And that’s not a great lesson to have taken.

busterarm 5y ago
I liken many of these situations in Python to the core team forcing their personal idiosyncracies on people rather than doing what's best. It's like how TCO will never make it into the language, or how the majority of http request libraries (certainly the most popular ones) reinvent the wheel by ditching libcurl, or how package management is a complete dumpster fire. The Python community in general certainly likes doing things their own way, even if that way is obtuse to the extreme. Instead of dealing with it, I moved on and delibererately extract it from my professional life at every company I go to, to great success. Luckily my job is to deploy things at very large scale and the argument to rewrite all Python as Go (or some other fast, compiled language) is extremely easy to make.
- creamytaco 5y ago
  I'm doing the same thing, except it's Rust and Go that I'm pushing (and more often than not, succeeding in getting through). Python is a liability at this point, not only because of performance but primarily due to it being badly designed. This bad design is at the core of every major Python debacle.
  - shawnz 5y ago
    The parent's point seems to be that Python is too opinionated. But aren't Rust and Go even more opinionated, particularly Go? What makes you think Go et al won't continue to make highly opinionated decisions like Python did through its development?
    - busterarm 5y ago
      I wouldn't exactly say that. I'm fine with strong opinions made for the greater good. Python's opinionation tends to be to satisfy personal itches people have. Often the justifications aren't good enough for the results. I have my criticisms of Golang and Rust as well, but Go is finally getting generics. It's not that they were never open to it, but the proposal needed to be good. Rust seriously needs to stop this rustup, curl | sh nonsense as an install method though. It's really embarrassing for a language that goes around beating everyone over the head about how secure it is. Rustup.rs is an enormous target if you want to go and sneak malicious code out into the world.
      - shawnz 5y ago
        I think everyone's opinion of how to achieve the greater good could be construed as just a "personal itch". I am not sure there even could be a singular "greater good" which would be best for everyone. Furthermore it's often not obvious what the results will be until the design is used in practice. There are lots of decisions that Go has made where I don't see them as clear and obvious wins, but I could be convinced after seeing how developers incorporate the ideas into their code. Newer languages have an advantage here, because if their opinions turn out to be unsuccessful, then people will just forget about the language. They won't feel like a language they previously liked was made worse, like some felt with the Python 2->3 transition. But as languages like Go age, there will be more people to get upset with each change. So I worry that simply switching to a newer language doesn't really solve the problem, even if you feel like its opinions align well with your own at the current time.
        busterarm 5y ago
- StavrosK 5y ago
  > how package management is a complete dumpster fire Poetry finally solves all my woes. You can combine it with something like pyenv so you don't get confused with multiple versions on your computer, and then it just works.
shawnz 5y ago
Removing the prefixes is clearly a breaking change, but how is adding them back a breaking change? Anecdotally, I was mostly happy with the Python 3 transition and have been using Python 3 for basically all new Python code since. Not much will ever be improved if you never take any risks, so I think any kind of innovation necessarily includes "own goals". Obviously not all of them hit the mark, though.
- cletus 5y ago
  Yeah I should clarify this. So minor versions have always been able to remove packages (as per PEP 4) but, and perhaps this is just my perception more than reality, it seems like the breaking changes of Python 3.x have decreased the psychological barrier for doing that and Python is now more willing to remove old packages (eg PEP 594). Like the genie is out of the bottle now. It's interesting reading some of the comments on PEP 594 that say "well most of these libraries are in pure Python so you can just include them if you want them" and I'm like "uhhhh... doesn't Python have enough problems with dependency management?" I compare all this to Java, which to me is really the gold standard for avoiding breaking changes (whatever other faults Java may have).
  - pansa2 5y ago
    > the breaking changes of Python 3.x have decreased the psychological barrier for doing that Perhaps the 2-to-3 transition caused people who dislike breaking changes to move to other languages, leaving only those who are pro-breakage in charge.

by cletus 5y ago

busterarm 5y ago

I liken many of these situations in Python to the core team forcing their personal idiosyncracies on people rather than doing what's best. It's like how TCO will never make it into the language, or how the majority of http request libraries (certainly the most popular ones) reinvent the wheel by ditching libcurl, or how package management is a complete dumpster fire. The Python community in general certainly likes doing things their own way, even if that way is obtuse to the extreme. Instead of dealing with it, I moved on and delibererately extract it from my professional life at every company I go to, to great success. Luckily my job is to deploy things at very large scale and the argument to rewrite all Python as Go (or some other fast, compiled language) is extremely easy to make.

creamytaco 5y ago
I'm doing the same thing, except it's Rust and Go that I'm pushing (and more often than not, succeeding in getting through). Python is a liability at this point, not only because of performance but primarily due to it being badly designed. This bad design is at the core of every major Python debacle.
- shawnz 5y ago
  The parent's point seems to be that Python is too opinionated. But aren't Rust and Go even more opinionated, particularly Go? What makes you think Go et al won't continue to make highly opinionated decisions like Python did through its development?
  - busterarm 5y ago
    I wouldn't exactly say that. I'm fine with strong opinions made for the greater good. Python's opinionation tends to be to satisfy personal itches people have. Often the justifications aren't good enough for the results. I have my criticisms of Golang and Rust as well, but Go is finally getting generics. It's not that they were never open to it, but the proposal needed to be good. Rust seriously needs to stop this rustup, curl | sh nonsense as an install method though. It's really embarrassing for a language that goes around beating everyone over the head about how secure it is. Rustup.rs is an enormous target if you want to go and sneak malicious code out into the world.
    - shawnz 5y ago
      I think everyone's opinion of how to achieve the greater good could be construed as just a "personal itch". I am not sure there even could be a singular "greater good" which would be best for everyone. Furthermore it's often not obvious what the results will be until the design is used in practice. There are lots of decisions that Go has made where I don't see them as clear and obvious wins, but I could be convinced after seeing how developers incorporate the ideas into their code. Newer languages have an advantage here, because if their opinions turn out to be unsuccessful, then people will just forget about the language. They won't feel like a language they previously liked was made worse, like some felt with the Python 2->3 transition. But as languages like Go age, there will be more people to get upset with each change. So I worry that simply switching to a newer language doesn't really solve the problem, even if you feel like its opinions align well with your own at the current time.
      - busterarm 5y ago
StavrosK 5y ago
> how package management is a complete dumpster fire Poetry finally solves all my woes. You can combine it with something like pyenv so you don't get confused with multiple versions on your computer, and then it just works.

shawnz 5y ago

Removing the prefixes is clearly a breaking change, but how is adding them back a breaking change? Anecdotally, I was mostly happy with the Python 3 transition and have been using Python 3 for basically all new Python code since. Not much will ever be improved if you never take any risks, so I think any kind of innovation necessarily includes "own goals". Obviously not all of them hit the mark, though.

cletus 5y ago
Yeah I should clarify this. So minor versions have always been able to remove packages (as per PEP 4) but, and perhaps this is just my perception more than reality, it seems like the breaking changes of Python 3.x have decreased the psychological barrier for doing that and Python is now more willing to remove old packages (eg PEP 594). Like the genie is out of the bottle now. It's interesting reading some of the comments on PEP 594 that say "well most of these libraries are in pure Python so you can just include them if you want them" and I'm like "uhhhh... doesn't Python have enough problems with dependency management?" I compare all this to Java, which to me is really the gold standard for avoiding breaking changes (whatever other faults Java may have).
- pansa2 5y ago
  > the breaking changes of Python 3.x have decreased the psychological barrier for doing that Perhaps the 2-to-3 transition caused people who dislike breaking changes to move to other languages, leaving only those who are pro-breakage in charge.