Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

261–270 of 513 posts

Re: Python 2 removed from Debian

#261

Earlier quoted context omitted.

You mean the way rakudo took over the entire perl ecosystem when it finally arrived? I suspect a lot of the controversial decusions made doing the 2to3 migration by the python foundation was deliberately designed to avoid a situation similar to what happened to perl when the time came to cleanup some of the old cruft from the language.

The difference is that Perl 6/Raku was a huge change from Perl 5. For Python, the small improvements weren't worth the break in compatibility.

You underestimate how big of a change Python 3 actually was. Changing how strings and bytes are handled has a huge blast radius. It broke almost every library or application I worked on. Everything else was peanuts to that semantic change.

It was a necessary change too. Supporting Unicode strings or mixed-encoded strings was absolutely awful in Python 2 and almost not worth doing. Python 3 made that work properly.

Arguably, the only real mistake was using UTF-16 instead of UTF-8 for strings. But back then, nobody knew what would take off and Windows natively uses UTF-16, so...

Re: Python 2 removed from Debian

#262

Glad this is finally mostly over, but... that was bad. I wonder if the energy that had to be put into this migration by everyone involved was worth what seems to be relatively small improvements. The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is),…

For speakers of languages that cannot be written in ASCII-only, the importance of the improved unicode handling really cannot be overstated, especially for people new to programming.

Re: Python 2 removed from Debian

#263
post #231

I really feel like the community was a difficult pain in the ass during the 2->3 migration. There were breaking changes but I’m sure the Python maintainers didn’t expect the community to react so badly. Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community.

A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example.

The list of stuff that got hard / slow was long. Migration path was unnecessarily difficult as was compatible code. Somewhere around 3.4 it was like a light switch flipped and they started being more reasonable. ASCII handling improved (yes, not all internet protocol stuff is Unicode), they began making it easier to target 2/3 etc. but it was horrible to start. I’ve thankfully forgotten some of the details :)

Re: Python 2 removed from Debian

#264

Earlier quoted context omitted.

We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still…

The biggest danger in Python 2's unicode handling is that incorrect things somewhat worked (until you got a non-ascii character at which point it exploded or produced incorrect behaviour). I'm sure you could do things well in Python 2 with proper combinations of encode/decode, but it wasn't obvious where you even needed those because with ascii text, things "just worked" transparently. With Python 3 it's very obvious…

You could do things correctly in Python 2, but as soon as you used any third-party library in your project, chances were it is going to explode underneath you anyway.

In the early 2000s, I maintained an py2, wxPython app with the users having the system encoding win-1250; the effort to patch this was unbelievable. The migration to python3-style handling forced everyone to think about these issues, not just few people for which things were crashing. Even just popularizing the issue was great, until then, many maintainers of third-party libraries didn't even understand what is the problem that you want to "needlessly complicated" fix in their libs.

Re: Python 2 removed from Debian

#265
post #88
post #56

Earlier quoted context omitted.

IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA

> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then…

I bet that you did not watch the presentation.

Also, the fact that there is a talk with such a name does not mean anything other than that someone is out there trying to clarify what the transition is about.

(There could have been a video "Windows 7: Trust me, it's better than Windows XP" and you probably still would say that it showed that improvements aren't worth the switch for most users.)

Re: Python 2 removed from Debian

#266

Earlier quoted context omitted.

There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years. The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example. The fact that they removed syntax for Python 3 meant that all kinds of scientific…

Wait, if it didn't use any strings, then it didn't use the print statement either, right?

For printing it's not a problem because a string containing unicode will be transparently printed in both Python 2 and 3 (at least on Linux/Mac, not sure how Windows deals with it).

It's also not a problem if you only have ASCII strings.

Re: Python 2 removed from Debian

#267
post #231

I really feel like the community was a difficult pain in the ass during the 2->3 migration. There were breaking changes but I’m sure the Python maintainers didn’t expect the community to react so badly. Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example. The list of stuff that got…

The era of "move fast and break things" was disastrous for a lot of things.

Re: Python 2 removed from Debian

#268

Having primarily used Python 3 since 2016 with some very specific (rare) exceptions and having found the switch remarkably pain free it's difficult to empathize with those still going on about this like it was massive, and yet there are major banks still struggling with the transition in key areas so there must be something. Is there a risk it becomes like one of those situations where certain people use a topic simp…

I worked on a code base which had a large dependency not port to Python 3 until 2018, and at the same time they made a huge ton of changes to the APIs, most of which were not documented well. So there was both a big refactoring to handle binary data transfer between it and the application, and also a ton of other unrelated things just to make it work. It's things like that that made it difficult to port for most people.

Re: Python 2 removed from Debian

#269

Earlier quoted context omitted.

I do like the optimistic worldview of execs being like "version 2?! version 2 sucks!! I want version 3, of that thing you just said"

Ha ha, well that was almost the CEOs verbatim reaction at a multi-billion dollar company. It helps if you are a financial services company and also add on "and if we dont do it, our web frameworks will reach EOL and have no more security updates"

The trick is "financial services" and "no security updates"

Re: Python 2 removed from Debian

#270
post #231

I really feel like the community was a difficult pain in the ass during the 2->3 migration. There were breaking changes but I’m sure the Python maintainers didn’t expect the community to react so badly. Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.

The python maintainers went out of their way to break things - and were smug about it. That’s what it felt like to the community. A big part of 3 was Unicode strings. In 2 you could mark a string as Unicode with a u””. This would have been a great way to let libraries and code work with both 2 and 3. They banned this, but you had to still use b””. This was the attitude and just one example. The list of stuff that got…

> Migration path was unnecessarily difficult as was compatible code.

I feel this take is outright wrong. Python provided it's 2to3 tool[1] which took care of the bulk of the work required to port Python2 code to Python3. The only code that was not supported was eggregious errors in the code that worked by coincidence, such as handling bytes as strings and vice-versa. Porting old code to Python3 is a breeze that consisted of running 2to3, run tests with python3, and if anything breaked then just touch up the code to get it to work. I know it because I personally ported half a dozen projects throughout the years.

I'll go as far as to claim that most problems porting old python code to 3 were either upstream dependencies dragging their feet or internal human/organizational issues.

[1] https://docs.python.org/3/library/2to3.html

Post reply on HN