Sunsetting Python 2
Python Software Foundation (Hacker News):
We have decided that January 1, 2020, will be the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.
[…]
We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020.
It’s been a long transition because the initial releases of 3.x were rough, broke a lot of code, and didn’t seem to offer compelling reasons to upgrade. Even if you wanted to upgrade, your code might have dependencies that hadn’t yet. So it kind of followed the path of Perl 6, even though it was a much less ambitious update.
Contrast this with Swift, where there’s a little breakage each year, which people complain about, but most active code (unfortunately not most code posted on the Web) does get updated rather quickly. Granted, Swift had the benefit of a smaller and younger installed base.
If you need to get fixes for Python 2, there’s Tauthon (via Hacker News):
Tauthon is a backwards-compatible fork of the Python 2.7.16 interpreter with new syntax, builtins, and libraries backported from Python 3.x. Python code and C-extensions targeting Python 2.7 or below are expected to run unmodified on Tauthon and produce the same output.
Victor Stinner (via Hacker News):
Python 3.0 was released 10 years ago. It’s time to look back: analyze the migration from Python 2 to Python 3, see the progress we made on the language, list bugs by cannot be fixed in Python 2 because of the backward compatibility, and discuss if it’s time or not to bury Python 2.
Let me translate this: filenames, command line arguments, and so on are no longer portable abstractions. They fundamentally mean different things on Unix and on Windows. On Windows, they are ‘Unicode’ (actually UTF-16) and may include characters not representable as single bytes, while on Unix they are and remain bytes and may include any byte value or sequence except 0. These are two incompatible types, especially once people start encoding non-ASCII filenames or command line arguments on Unix and want their programs to understand the decoded forms in Unicode.
[…]
I’ll note that Python 2 is not magically better than Python 3 here. It’s just that Python 2 chose to implicitly prioritize Unix over Windows by deciding that filenames, command line arguments, and so on were bytestrings instead of Unicode strings. I rather suspect that this caused Windows people using Python a certain amount of heartburn; we probably just didn’t hear as much from them for various reasons.
Python Software Foundation (via Hacker News):
“Python’s batteries are leaking,” said Brown. She thinks that some bugs in the standard library will never be fixed. And even when bugs are fixed, PyPI libraries like Twisted cannot assume they run on the latest Python, so they must preserve their bug workarounds forever.
[…]
Brown identified new standard library features that were “too little, too late,” leaving users to depend on backports to use those features in Python 2. For example,
socket.sendmsgwas added only recently, meaning Twisted must ship its own C extension to usesendmsgin Python 2. Although Python 2 is nearly at its end of life, this only holds for the core developers, according to Brown, and for users, Red Hat and other distributors will keep Python 2 alive “until the goddam end of time.”[…]
Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
Anthony Shaw (via Hacker News):
One of the features proposed for CPython 3.8 is PEP554, the implementation of sub-interpreters and an API with a new interpreters module in the standard library.
This enables creating multiple interpreters, from Python within a single process. Another change for Python 3.8 is that interpreters will all have individual GILs[…]
Previously:
