5 ms·

Thank goodness. They went out of their way to break things and make the 2 to 3 transition hard - burned and wore out a lot of people. Remind me why things lik

Thank goodness. They went out of their way to break things and make the 2 to 3 transition hard - burned and wore out a lot of people. Remind me why things like u"" couldn't be used to help cover exist codebases?

pansa2 5y ago
> Remind me why things like u"" couldn't be used to help cover exist codebases? It’s right there in the Zen of Python: “Purity beats practicality”. Wait, no...
- whoknowswhat11 5y ago
  The part that was so annoying is that if unicode is great - then letting us use the nonconflicting u"" would have let us bring 2.0 libraries into 3.0 land much more easily while ALSO improving 2.x libraries. And with no pain really. If they needed to they could have a done a --compat flag. It wasn't until 3.3 and then 3.4 that there was finally some give. We got u"" back. We also go some ability to handle the net (ASCII / Binary Transform stuff) in a quasi sensible way. But boy - was it a screw you until then. And I got seriously tired of having folks who don't actually maintain any code lecturing on and on about how this was the better way. Sure - if you are in a monorepo. But not if you are library author supporting endless versions of python!
- busterarm 5y ago
  It's partly that but partly completely not understanding how hopelessly broken their packaging system is and the burden that's put on popular library authors that encourages them to have extremely wide compatibility.
protomikron 5y ago
Actually I think the transition to Python3 went pretty well. Most people are on 3 now, and Python's ecosystem is thriving.
- Cthulhu_ 5y ago
  It only took 13 years.
  - Kye 5y ago
    How long does it normally take to transition the community around a programming language to a new version that makes substantial changes?
    - dagw 5y ago
      Ruby 1->2 and php 4->5 and 5->7 went a lot faster. On the other hand getting everybody from Fortran 90 to Fortran 2008 will probably take at least one more decade ;)
    - magicalhippo 5y ago
      Depends on what you mean by substantial changes, but Delphi changed its string type from ANSI to Unicode some time ago, similar to what Python did. For the vast majority of users it was a very easy transition, due to the substantial work done by the Delphi team to make it so. For a lot of programs, a mere recompilation was required. We had a 300kLOC program + dependencies at that time, and one of us spent a 2-3 days on migrating, fixing small issues and testing.
- goodoldneon 5y ago
  My company had to spend a ton of engineering time to migrate to 3
  - busterarm 5y ago
    Still not done. Plus the burden of having to upgrade applications that don't make sense to from a financial perspective is totally not cool.
    - treesknees 5y ago
      We've barely started (we produce embedded router/fw appliances.) We've written up our backlog items to start tackling it but when you're under a constant crunch to get features and bug fixes out the door, PM will never prioritize willingly introducing subtle bugs across the entire codebase unless there's an extremely strong reason to upgrade. Unfortunately "no longer receives security updates" isn't strong enough. Until we can't ship a new feature without Python 3, we'll be on 2 for a long time.
raverbashing 5y ago
The earlier versions of 3.x (3.0, 3.1, etc) yes they sucked. But then again you didn't have to switch immediately. But it was kinda "expected" that these first versions were a bit unstable. Now people are using that as an excuse to say "Python 3 is bad?" No, sorry. I'm happy they went from ASCII to Unicode. (hey, people didn't want to use 'setdefaultencoding' for pure BS reasons, so, yeah, you got it coming!)
- dagw 5y ago
  The main problem wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. In an alternate universe where the python core developers had coordinated with a handful of the most popular libraries and announced 3.0 with at least usable beta versions of those libraries being available then I imagine the reception being very different.
  - raverbashing 5y ago
    > wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. Well, that counts to me as a version fault as well (especially since things like venv were green to say the least), but yes, a coordination would have been helpful. Though it's a bit of a chicken/egg problem.
  - zerkten 5y ago
    There wasn't an expectation that libraries would work nor was there an expectation that the transition should be quick. That's from listening to conversations at PyCon 2008 and 2009. Back then I got the feeling that this would result in a bumpy ride later on, but accepted it because I was new to Python. It has similarities to how packaging was treated historically. I think this precipitated a number of other problems which meant that by Python 3.3 and 3.4 inertia had set in. There appeared to be a bit of a panic that code wasn't being brought over from Python 2. This resulted in flipflopping on a recommended approach which I would argue was an unnecessary problem. There should have been a deeper assessment of the situation. It was was only in this timeframe that differentiated features started appearing for CPython 3. My experience from the PyCons when CPython 3 was in the early versions was that attention went to possible alternative runtimes. There was a lot of energy going into PyPy, Unladen Swallow, and the like while language features for regular devs were limited. It's only later that a coherent strategy started to form around porting libraries, providing clear and unchanging guidance on migration to Python 3, and big projects committed to migrating. I'm missing a few things, but this combination started to build real momentum. The backend runtime stuff and the limitations of CPython still existed, but Cython and other tools helped ML usage of Python grow. I don't think people who weren't Python fans would have predicted that given the performance constraints.

pansa2 5y ago

> Remind me why things like u"" couldn't be used to help cover exist codebases? It’s right there in the Zen of Python: “Purity beats practicality”. Wait, no...

whoknowswhat11 5y ago
The part that was so annoying is that if unicode is great - then letting us use the nonconflicting u"" would have let us bring 2.0 libraries into 3.0 land much more easily while ALSO improving 2.x libraries. And with no pain really. If they needed to they could have a done a --compat flag. It wasn't until 3.3 and then 3.4 that there was finally some give. We got u"" back. We also go some ability to handle the net (ASCII / Binary Transform stuff) in a quasi sensible way. But boy - was it a screw you until then. And I got seriously tired of having folks who don't actually maintain any code lecturing on and on about how this was the better way. Sure - if you are in a monorepo. But not if you are library author supporting endless versions of python!
busterarm 5y ago
It's partly that but partly completely not understanding how hopelessly broken their packaging system is and the burden that's put on popular library authors that encourages them to have extremely wide compatibility.

protomikron 5y ago

Actually I think the transition to Python3 went pretty well. Most people are on 3 now, and Python's ecosystem is thriving.

Cthulhu_ 5y ago
It only took 13 years.
- Kye 5y ago
  How long does it normally take to transition the community around a programming language to a new version that makes substantial changes?
  - dagw 5y ago
    Ruby 1->2 and php 4->5 and 5->7 went a lot faster. On the other hand getting everybody from Fortran 90 to Fortran 2008 will probably take at least one more decade ;)
  - magicalhippo 5y ago
    Depends on what you mean by substantial changes, but Delphi changed its string type from ANSI to Unicode some time ago, similar to what Python did. For the vast majority of users it was a very easy transition, due to the substantial work done by the Delphi team to make it so. For a lot of programs, a mere recompilation was required. We had a 300kLOC program + dependencies at that time, and one of us spent a 2-3 days on migrating, fixing small issues and testing.
goodoldneon 5y ago
My company had to spend a ton of engineering time to migrate to 3
- busterarm 5y ago
  Still not done. Plus the burden of having to upgrade applications that don't make sense to from a financial perspective is totally not cool.
  - treesknees 5y ago
    We've barely started (we produce embedded router/fw appliances.) We've written up our backlog items to start tackling it but when you're under a constant crunch to get features and bug fixes out the door, PM will never prioritize willingly introducing subtle bugs across the entire codebase unless there's an extremely strong reason to upgrade. Unfortunately "no longer receives security updates" isn't strong enough. Until we can't ship a new feature without Python 3, we'll be on 2 for a long time.

raverbashing 5y ago

The earlier versions of 3.x (3.0, 3.1, etc) yes they sucked. But then again you didn't have to switch immediately. But it was kinda "expected" that these first versions were a bit unstable. Now people are using that as an excuse to say "Python 3 is bad?" No, sorry. I'm happy they went from ASCII to Unicode. (hey, people didn't want to use 'setdefaultencoding' for pure BS reasons, so, yeah, you got it coming!)

dagw 5y ago
The main problem wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. In an alternate universe where the python core developers had coordinated with a handful of the most popular libraries and announced 3.0 with at least usable beta versions of those libraries being available then I imagine the reception being very different.
- raverbashing 5y ago
  > wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. Well, that counts to me as a version fault as well (especially since things like venv were green to say the least), but yes, a coordination would have been helpful. Though it's a bit of a chicken/egg problem.
- zerkten 5y ago
  There wasn't an expectation that libraries would work nor was there an expectation that the transition should be quick. That's from listening to conversations at PyCon 2008 and 2009. Back then I got the feeling that this would result in a bumpy ride later on, but accepted it because I was new to Python. It has similarities to how packaging was treated historically. I think this precipitated a number of other problems which meant that by Python 3.3 and 3.4 inertia had set in. There appeared to be a bit of a panic that code wasn't being brought over from Python 2. This resulted in flipflopping on a recommended approach which I would argue was an unnecessary problem. There should have been a deeper assessment of the situation. It was was only in this timeframe that differentiated features started appearing for CPython 3. My experience from the PyCons when CPython 3 was in the early versions was that attention went to possible alternative runtimes. There was a lot of energy going into PyPy, Unladen Swallow, and the like while language features for regular devs were limited. It's only later that a coherent strategy started to form around porting libraries, providing clear and unchanging guidance on migration to Python 3, and big projects committed to migrating. I'm missing a few things, but this combination started to build real momentum. The backend runtime stuff and the limitations of CPython still existed, but Cython and other tools helped ML usage of Python grow. I don't think people who weren't Python fans would have predicted that given the performance constraints.