Hacker News Reader

Comment by jacquesm | Hacker News Reader

And not a decade too soon. The Python 2 -> Python 3 migration will be studied for a long time as an example how not to release a new version of your language or library, right next to that Angular thingy. The number of headaches I've had to deal with because of this over the years have just about soured me on the whole Python offering, and I used to be a pretty big fan.

Great that Debian finally pulls the plug on it, that means that most if not all of the downstream distros (such as Ubuntu) will probably follow suit, that's a big fraction of the whole Linux eco-system.

View on HN

Forgive my ignorance, but what should have been done instead of the way the Python 2 to 3 migration happened?

I know that Python 2 has stuck around for far longer than anyone wanted and that people were (are?) hesitant to migrate from 2 to 3, but I'm not sure what decisions contributed to that.

IMHO: Early versions of Python 3 were outright inferior, and IIRC couldn't handle raw bytes, because "everything should be Unicode". Except, not everything is Unicode. So people went to port, and couldn't. This compounded a problem with libraries, to create a situation where transitioning was risky. Better yet, eventually the Python devs decreed that everyone should move already... so they were going to stop making new 2.x feature releases, and only issue big fixes. But to the folks already hesitant to change, that sounded a lot like "Python 2 will be super Stable for forever".

So IMO, basically what should have happened is accounting for valid use of features that 3 wanted to kill, and actually offering a path forward, from day one, so everyone could do a migration and actually have it work.

Edit: Also (but connected), 3.0 (and IIRC a couple thereafter) should have been marked as release candidates, because they were.

I think you are making some really good points, the fact that the bulk of the initial bugs were found by users and not by the developers is what caused initial adoption of V3 to run into an immediate roadblock. If that had not happened the whole thing might have gone over a lot faster but it caused a lot of people to go from 'Yay, UTF-8 strings' to 'wait and see and let someone else handle the bugs, we'll check back in a year (or two, or five)'.

Just maintain backwards compatibility.

For us it was a change in string handling that stopped us being able to upgrade. Literally 10,000 things would have to be checked. We saw that red hat was supporting python 2 until 2025 so we decided to keep using python 2 until then. I think that once red hat stops supporting python 2 someone else will keep it running.

Python 2 still makes the world go round.

I think the biggest issue was that they named the executable same. They backported few things from python 3 to 2.7, and recommended to use `sys.version_info` and `__future__` for making code run in both python. If they said they would never rename python3 executable to python and python3 is not python, it would have been easier for everyone.

They should have made the Python 3 interpreter able to embed the Python 2 interpreter. It would’ve then been possible to mark projects as 3 while they continue to import 2 libraries.

This is similar to Rust's approach of using language "editions" separately from compiler versions (presumably because they learned from this migration).

I don't think that the Angular.js -> Angular update/rebrand is on the same level. Migrating a codebase from Python 2 to 3 feels like a "port", doing the same for Angular feels more like a rewrite. :-)

Yes, it is nice to see the python 3 migration is pretty much done, it really could have happened literally a decade ago! While we're all here: which is the package manager to use?

I've sort of bypassed the whole package manager thingy by using 'Anaconda', it's served me very well so far by insulating me from those particular gotchas.

https://www.anaconda.com/

Some would consider it cheating but I haven't got enough hours in the day. If I were to write some ad copy for Anaconda it would be 'in several years of frequent use this particular user didn't have to resolve a single conflict, it all just worked'.

Which runs counter to just about all of my other experiences with Python and its package managers/distributions/toolchains, some of those stories would end with 'and as a result the whole server was hosed starting from what should have been a routine certificate update' and other such nice adventures.

got it - thanks!

If you're installing a command-line tool globally, I usually go for the system package manager (e.g. `apt` on debian), or `pip` if I want a newer version. With pip, make sure to use the `--user` flag so things aren't installed with root.

If you're writing Python code, `poetry` has been the least bad package manager in my experience. It has a lock-file, so it should help avoid supply-side attacks (like the PyTorch one from a few days ago [1]), and it means your local environment and CI/CD environment should have the same packages installed.

I'd also recommend setting the [`virtualenvs.in-project`][2] setting to `true`, to store the `.venv` in the same folder as your code, so that when you delete your code, all of the downloaded packages get deleted too. Otherwise they'll just stick around in your user directory and use up a lot of disk space.

[1]: https://pytorch.org/blog/compromised-nightly-dependency/

[2]: https://python-poetry.org/docs/configuration/#virtualenvsin-...

> which is the package manager to use?

pip

Unless you are doing scientific computing or using Windows in which case you should use anaconda. Oh and if you are on a Mac you you use brew if you want to install things like tensorflow or imagemagick etc. You see there's only one thing to do it TM :)

Anaconda works very well on Linux.

I agree. Yet still most people doing scientific computing will end up with 17 installations on their system. I was just being facetious about the state of package management :)

My team is using Poetry.

Did you know pip can execute arbitrary code when installing packages?

Just fyi Poetry is still using pip under the hood. Also (unrelated to Poetry’s pip usage) if you ever build a dependency from source (the situation where pip executes arbitrary code), Poetry also executes arbitrary code.

I use poetry but regardless as soon as you import a library arbitrary code is executed.

Reply on news.ycombinator.com