Hacker News Reader

Hacker News

Comment by whoknowswhat11 | Hacker News Reader

Parent Full thread

whoknowswhat11

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?

View on HN

> 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...

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!

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.

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!)

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.

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.

> 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.

But the intentionally seemed to screw folks who needed ASCII - and hey - a lot of web protocols were ASCII at the time.

Sure, do the unicode thing. But if someone needs to deal with ASCII they need to deal with it. And python 3 was pathetic here. Some folks wrote some very clear posts about this I wish I could find as they explain it a lot better than I ever could.

> But if someone needs to deal with ASCII they need to deal with it.

Of course. Also byte strings were not there yet IIRC in those earlier versions.

But you could deal with it. .decode/.encode to ASCII never stopped working

But beats annoying the rest of the world that needed to deal with non ASCII strings.

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

3 came out in 2008. [0] I don’t think 13 years is “pretty well.”

There was still lots of python2 package installs [1] even after 2.x officially ended.

[0] https://en.wikipedia.org/wiki/History_of_Python [1] https://dev.to/hugovk/python-version-share-over-time-6-1jb8

The original plan was to have a transition period of about 10 years. Didn't we have almost exactly that?

The original plan was for Python 2 support to end in 2015.

My company had to spend a ton of engineering time to migrate to 3

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.

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.

We're in a similar state for web apps: No one wants to put extensive developer time on something with nothing new to sell.

It's this + they broke stuff that didn't need to be broken + made it hard / impossible to target both 2 and 3 and/or code incrementally in 3 on top of a 2 code base.

The other nightmare is if a dependency isn't actively maintained you have also port your DEPENDENCIES over. Straight waste of time in many many cases. And your PM is asking (fairly) what new cool feature do we get? And you say - the program will run more slowly after all this stupid work. And boy - did things run more slowly especially in the early version - you upgraded and then got crap as a result so PM is asking why all this work made things WORSE for users.

It only took 13 years.

How long does it normally take to transition the community around a programming language to a new version that makes substantial changes?

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.

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 ;)

Reply on news.ycombinator.com