Live data from Hacker News

Python 2 removed from Debian

bugs.debian.org

251–260 of 513 posts

Re: Python 2 removed from Debian

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

Guido has done some pycon keynotes in the recent past and said himself he takes some of the blame for the transition. He says he greatly underestimated the impact of breaking changes and the inertia to get the community to change code. In particular not shipping tools to help automate the migration, or even thinking through a migration path with targeted backwards compatibility/back ports from the start (these eventually came quite a few releases and years into the transition). I don't think it's fair to say the community was entirely at fault for the length of time.

edit: This talk he did from pycascades 2018 in particular I remember seeing and being a good retrospective: https://www.youtube.com/watch?v=Oiw23yfqQy8

Re: Python 2 removed from Debian

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

Guido has done some pycon keynotes in the recent past and said himself he takes some of the blame for the transition. He says he greatly underestimated the impact of breaking changes and the inertia to get the community to change code. In particular not shipping tools to help automate the migration, or even thinking through a migration path with targeted backwards compatibility/back ports from the start (these eventu…

Codemods aren't a thing in Python?

Re: Python 2 removed from Debian

#253

Earlier quoted context omitted.

Python had that long before js, with __future__ imports. But editions & friends are for syntax. Python 3 changed semantics all around. Editions are not an option when you’re changing the langage’s entire text model, especially without static typing.

Could they have at least minimised the blast radius? For example, make all of the text/Unicode changes for Python 3 and thats it . Python 3.1 could then have introduced some of the other minor changes, perhaps behind a future import. I had a hand in moving from 2.7 to 3.6 for a 1M LOC repo and it was not pleasant. So many backward compatible changes that that all had to be accounted for rather than being able to focu…

> Could they have at least minimised the blast radius? For example, make all of the text/Unicode changes for Python 3 and thats it.

Most of the other changes were kind of trivial though. print → print(), some stdlib name changes: that's easy stuff; you can automate that, even provide a compatibility shim. The division operator was a bit more tricky, but I never encountered code that broke due to it (although I'm sure some did, it didn't seem like a wide-spread issue). Plus you could do most of these things in Python 2.

> It seems that a bunch of changes were made all at once because it was already going to be incompatible so let’s take the opportunity to clean up as much as possible.

You should have seen the initial discussions surrounding Python 3000, as it was called back then. The most common thing Guido had to say was "No, that's far too large of a change, we're not designing a new language", even for things where it was agreed on that the situation wasn't ideal. The community came up with some pretty wild proposals, and a lot was kept out of Python 3.

Re: Python 2 removed from Debian

#254
post #88

Earlier quoted context omitted.

> "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…

> 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. That's reading far too much into a tongue in cheek presentation title. Besides, good devs are typically reasonably skeptical of new and shiny. And when you've got a large Python 2.7 codebase, and Python 3 is backwards incompatible, you'd be looking at a lot of work to upg…

OCaml 5 recently solved the global lock problem by introducing concurrent domains in which one or more threads share a lock. So old code keeps spawning threads with a shared lock, but new code can work with single-thread domains and manage in which domains does old code run.

Re: Python 2 removed from Debian

#255
post #186

Earlier quoted context omitted.

> It will be easier for the Python core maintainers, [...] It wasn't not even that easy, to be frank. 2to3 is not a small project [1] and they had (alas, incorrectly) assumed that there were enough people to have enough tests to be benefited from 2to3, only to be found massively wrong. In hindsight no one had a good idea about language evolution; the modern concensus is a single interpreter supporting multiple parall…

> In hindsight no one had a good idea about language evolution; the modern concensus is a single interpreter supporting multiple parallel versions, also called "editions", but (EDIT: to my knowledge) the first major language with this approach was ECMAScript 2009 (5th ed.) with `use strict` and Python 3 predated it. Perl did it since ages. You just put use v5.24 in header and interpreter enabled those language featur…

Perl's behavior was utterly broken. It worked more like how a C/C++ compiler handles language standards (by lying to you) than actually enforcing behaviors.

From the toolchain and language developer side, nobody liked Perl's approach. That's why there was so much effort around Perl 6 (which became Raku) at around the same time.

Re: Python 2 removed from Debian

#256
post #118

Meanwhile we are still living our Python 2 like moments in .NET and JVM ecosystems, with the huge amount of projects stuck in .NET Framework and Java 8, with no end in sight of them ever moving forward.

My previous, and only, software developement job involved migrating a monolithic .NET Framework web app to .NET 5.0

Compared to Python 2->3, the breaking changes were more obvious as they involved entire strucutres and paradigms being deprecated. Python 2->3 felt a lot more subtle despite being just as damaging.

Re: Python 2 removed from Debian

#257
post #184

Earlier quoted context omitted.

The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to something old to not break old stuff) The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl. At the very least they should've just made new one…

Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.

No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts.

The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.

Re: Python 2 removed from Debian

#258
post #252

Earlier quoted context omitted.

Guido has done some pycon keynotes in the recent past and said himself he takes some of the blame for the transition. He says he greatly underestimated the impact of breaking changes and the inertia to get the community to change code. In particular not shipping tools to help automate the migration, or even thinking through a migration path with targeted backwards compatibility/back ports from the start (these eventu…

Codemods aren't a thing in Python?

They are a thing, the ast module was created to help with the transition and tooling to automate some of the conversion: https://docs.python.org/3/library/ast.html IIRC it wasn't there at the start though.

Re: Python 2 removed from Debian

#259
post #243
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.

> Are there some valid reasons that made 2->3 migration insanely hard for some projects? Print was a non-issue once you could do "from __future__ import print_function". It was the unicode migration. All string handling from I/O required at least checking. The dependency issue was the most crippling, though: because you can't load Python 2 code from Python 3, before your project can begin migrating you have to wait f…

Sounds like a circular problem

Re: Python 2 removed from Debian

#260
post #188

Earlier quoted context omitted.

Well, trying to sell a project to the higher-ups is a lot easier when you can say > Hey our interpreter for our backend code will be eventually deprecated. It is currently version 2 and we need to move to version 3" Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: > Hey, there is a new interpreter out there called COBRA. We need to rewrite our who…

> Then the execs say "we are on 2?? and there is a 3??! what are we waiting for?!" A whole lot easier than trying to say: Nope, the real life conversation would be "Is 2 still supported ? Yes ? Well then we will migrate when it won't"

Depends on the executive. I usually got a variation of "go do it NOW, while also fixing all the bugs and add features at the same time".
Post reply on HN