It will be decades before the final Python 2 program goes offline.
Mumble mumble something about conflating languages with implementations.
It will only get more difficult to maintain your app.
[1] https://python3statement.org/ - note many libraries weren't even waiting until 2020. It is a lot of work to maintain code with python 2 cruft. Not all packages are listed there, for example Django is Python 3 only, starting from 2.0 (currently at 3.0)
So your claim is that "Python 2" is a language spec, not an implementation? And that there will be future releases of this language spec in the future? I doubt it.
I agree it's likely that there will be people wasting their time maintaining an interpreter fork, but that will not be Python-the-language (a trademarked term BTW), it will be a fork of the implementation.
Audit all strings coming in and going out for encoding issues. Update all dependencies to their python 3 equivalent. Replace dependencies that hadn’t been updated (typically older django dependencies). Use python-future to bulk update incompatibilities. Changes to metaclasses were annoying. Force all uses of pickle to use protocol version 2. I documented some more during the migration on Twitter https://twitter.com/jarshwah/status/1209381850822496256?s=21
We began getting the code base into a compatible position about 1.5 years earlier. A final push of 3-4 weeks of work got it over the line, with many bug fixes after the deployment.
Other older larger systems will have similar problems at a larger scale.
This isn’t a condemnation by the way. Python 3 is better. The only reason we held out so long was because of the business justification. Once we couldn’t wait any longer it got prioritised.
One industry example is https://vfxplatform.com/ - they just (this year) moved to Python3, but with some delays, from the site:
The move to Python 3 was delayed from CY2019 to CY2020 due to:
No supported combination of Qt 5.6, Python 3 and PySide 2 so Qt first needed to be upgraded.
Upgrade of both Qt and Python in the same year was too large a commitment for software vendors and large studios.
Python 3 in CY2020 is a firm commitment, it will be a required upgrade as Python 2 will no longer be supported beyond 2020. Software vendors are strongly encouraged to provide a tech preview release in 2019 to help studios with testing during their Python migration efforts.The string-handling changes, while necessary, are also a bear to deal with. Since python is dynamically typed, you need to work to find all the places where you need to add a ".decode()" or ".encode()". If you don't have excellent test coverage already, you're going to miss some, and it'll be a game of whack-a-mole until you get them all... assuming you have actually gotten them all.
Although there are ways, you can still incrementally adapt code base to work on both pythons. Also pylint with py3k option, mypy can help. There's also six packages, but many people seem to had good luck with futurize.
There's also something that I tried a while ago and it surprisingly worked (although it might not work that well on larger codebase?), basically you can use Cython (not to be confused with CPython) to compile Python 2 code and then include it in python 3, this would enable migration file by file.
I'm not looking forward to the scramble when it does upgrade, as we're using a ton of community modules that may or may not be abandoned.
Knowing researchers (at least in academia), they're the last people I would expect to change.
> time pypy mandel.py > pypy.pgm
seconds: 0.318101
real 0m0.426s
user 0m0.396s
sys 0m0.013s
> time python2 mandel.py > python2.pgm
seconds: 30.141954
real 0m30.156s
user 0m30.136s
sys 0m0.003s
I'm not in any way associated with the PyPy project, but I can't help but believe a sane world would've moved from Python to PyPy in the same way everything moved from Brandon Eich's original JavaScript interpreter to the modern JIT ones like V8.
[0] https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
Yes, and this is my fundamental complaint with the Python 3 transition. It took probably millions of engineer-hours, and the result was better Unicode support and a handful of minor features most of which could have been added to Python 2 just as easily. I suspect most users would gladly have traded those benefits for a 10x performance improvement.
Yes, and I wish the better Unicode support had been implemented similarly to how Go does it - one string type, and you use it to hold UTF-8 if needed. In other words, they could've simply deprecated the Python 2.X unicode object and added libraries to extract code points, or grapheme clusters, or perform normalization etc... This seems much simpler and more "Pythonic".
I guess everything is 20/20 in hindsight.
Different Unicode support. And worse bytes support.
What could previously be done using python -c "..." is now long, horrible and ugly.
Contrast with Java, which has made much more substantial changes to the language over all these years, but goes to great pains to support backwards compatibility. Upgrading major Java versions was never remotely as painful, and as a result, huge amounts of engineering time was saved.
I guess it's a matter of emphasis, but I'd say it has different Unicode support. It's better mildly for some use cases, but worse for others.
It's bloody horrible for one use case in particular: when you know the text is readable and mostly ASCII based and you are only interested in the ASCII bits, but don't know the encoding. That is the position you find yourself in for any designed in pre-unicode times, and that happens to include just about every file in a Unix file system.
The solution in those circumstances is to treat everything as bytes (b''). That wasn't even possible in the beginning. Now it mostly works, but all with hundreds of corner exceptions (like Exception messages, so you can't easily include a Unix filename in an error message).
But yes the only people who wanted better unicode were web people. So they could have been better served moving to pypy.
def mandel(data: np.ndarray):
c = data
z = c
for j in range(255):
z = z**2 + c
Moreover, for some very common things in signal processing, like working with evens/odds or left/right parts of an array, the parallel numpy operation will create lots of temporary arrays and copies.
And for what it's worth, your version of mandel should work with PyPy. So you can have your cake and eat it too.
EDIT: I should add the reason my code is "strange" is because I wrote it so I could do a one-to-one comparison with other languages which don't have builtin complex numbers. Maybe I should've cleaned that up before posting.
Just do yourself a favor and migrate your codebase, Py3 is much more enjoyable to program in. I feel like all those vocal Python 2 supporters never had a chance to write a new code in Python 3. If you only did 2->3 migration you might hate Python 3, because it doesn't let you run a broken code that Python 2 happily executed, but if you can write Python 3 app from scratch you don't even notice the unicode, text is just text.
I think that's unfair. There was plenty of code that was out there for 10 years or more that was working completely fine and had to be ported. One of the most frustrating things I had to do was completely rearchitect some legacy binary file reading/writing because of the changes to how Python handled bytes. That code was out there as open source in the wild, stable, and was being widely used, and it basically required a full rewrite underneath the API.
One of the most frustrating things was that many packages we used as dependencies took ~5 years to port to Python 3, and then dropped Python 2 support immediately, leaving us with no choice but to use the old version for some time. We'd done a lot of the easy stuff already (2to3 on all files), but lots of the non-trivial things were the interactions with other packages so couldn't be touched until they had themselves got a Python 3 version.
Years ago I had a bunch of code that was basically just matrix multiplication with some large-ish matrices, and then taking some eigenvectors/eigenvalues at the end. At the time I found the same thing -- if I decomposed things into simple lists of numbers for vectors and lists of lists PyPy was way faster.
I just had the opportunity to brush this code off in Python 3 and run it as-is, and it performs much better than it used to. But I am always curious to hear about these cases.
PyPy really is a wonderful project.
sudo apt install pypy3
pypy3 -m pytest /my/python/app
I believe this is also a huge part of the reason why migrating from CPython version 2 to version 3 was delayed. I've adapted a few small C extension modules to run under both, and using #ifdef for the special cases to support both was unpleasant. So I imagine that any large package which needed to support both through the transition really suffered for it.
It's only relatively recently that Python 3 passed a certain threshold that made deprecation of Python 2 something that could actually be executed upon. Had the growth been slower in the last five years I think the timeline would have been different.
If I was going to critique Python "failures" I think the bigger target for me would be the integration of async concepts into the platform and language. This could have been handled more smoothly and with better community cohesion, but most HNers only have a superficial understanding, i.e the GIL is bad and Python can't compete with Go.
[1] http://python-notes.curiousefficiency.org/en/latest/python3/...
It was an immense amount of work for a fairly small payoff.
Ask the PERL and PHP communities how hard it is. PHP 6 ended up getting dumpstered and the “next” version of PERL was so different they had to change the name and the community never really recovered. Python has at least grown/ survived through the upgrade.
Python is now roughly #1.
Let the data tell the story, and not the other way around.
Also, it takes pretty vivid imagination / stout obstinance to characterize vast majority of pre-existing libs/projects and almost all new project starts using new version as a "failure".
Bunch of whining and FUD does not equate to failure.
Everyone who ships software knows that there is always a very small but disproportionately vocal set of malcontents who can't accept changes; that's their issue, not anyone else's.
Software using Python 2.7 won't magically disappear and I believe there is going to be a demand after fixes.
(I know about Tauthon but I don't think it applies here ...)
I'm willing to bet that the demand is not really there and most of this is just kvetching. Should have happened a long time ago.
I'm not aware of any good technical reason to still be using Python 2. There is the "I don't have time to upgrade" argument, and I recognize the cost is real. But now we'll see at last if people are willing to stick up for Python 2 more than just figuratively.
The industry is still not in the process of porting major pieces of the ecosystem.
It’ll be another 3-5 years i estimate
(most places i've worked at, when we do the calculations for the business it's much cheaper/less risky just to upgrade to python 3, rather than to support python 2 or switch languages)
Demand for fixes will occur but it would probably best be handled by a third party that would specialize in that or developing it internally.
But now we're back on that treadmill...
I do strongly feel that removing functions from the core library is a huge no-no for point releases.
python3 -c "import ast; print(ast.arguments([]).args)"
If I don't want to use OS packages, I have to decide to package, build, deploy, and maintain the Python packages, often in a way that separates it from the system Python package, while also managing any Python libraries we need (some of which may be C extensions and require compiling).
Whenever possible, I like to leverage upstream packaging so that I don't have to track security updates on my own.
I say this as someone who used to maintain the official Python.org RPM packages.
Anyone who thinks they do should go sign up for some COBOL training so they can grab those sweet New Jersey contracts. ;)
Like I said, I acknowledge there were costs to transitioning. Python 3 was pretty rough around the edges upon first release. But that first release was in 2008 ...
I realize not everyone needs to upgrade, and that's totally fine. But how people internally justify the cost of keeping Python 2 going when the momentum and most of the community is with Python 3 I cannot understand. Unless you're in a very inflexible corporate setting ...
Why did I not see this sentiment for C89 vs C99 for example?
Let me be clear: If people want to use Python 2 they can go nuts. They can even pretend it's a completely new language if they want to. If there's enough of them I'm sure it can be done. Just stop asking the community to support it, or the rest of us to care.
> As of January 1st, 2020 no new bug reports, fixes, or changes will be made to Python 2, and Python 2 is no longer supported. We have not yet released the few changes made between when we released Python 2.7.17 (on October 19th, 2019) and January 1st. As a service to the community, we will bundle those fixes (and only those fixes) and release a 2.7.18. We plan on doing that in April 2020
[1] Sunsetting Python 2: https://www.python.org/doc/sunset-python-2/
[2] When is the last release of Python 2.7 coming out?: http://python-notes.curiousefficiency.org/en/latest/python3/...
https://github.com/python/cpython/commits/2.7
This is the release of the changes up to that date, since they don't release instantly.
https://adtmag.com/articles/2020/01/09/python-2-end-of-life....
Once you're using containers, shared build tooling, and enforcing linting/testing, the version you use doesn't matter as much, imo. Unless you're using an advanced feature that's still developing (rare..only seen it a few times), most projects can upgrade minor version with zero codebase changes. Just lock a new environment, format code, and push to CI.
If you actually look at the issue discussing this, you can see that Guido is being more than amenable and the responses are honestly verging on childish.
IMO, Python 2 is a genericized trademark like Kleenex at this point.
I say it isn't a knock because I think they were equally fine with the goals: Perl was looking to make a bold break towards an unknown future [2], and Python wanted a very slow and sustainable migration.
I'm glad to see Python 3 go mainstream, I'm glad that Python 2 succeeded so well, and I'm glad there are segments of computer science that still throw mugs and aim for the moon.
[1] http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-...
[2] https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.h...
First, Perl will support multiple syntaxes that map onto a single semantic model. Second, that single semantic model will in turn map to multiple platforms.
Multiple syntaxes sound like an evil thing, but they're really necessary for the evolution of the language. To some extent we already have a multi-syntax model in Perl 5; every time you use a pragma or module, you are warping the language you're using. As long as it's clear from the declarations at the top of the module which version of the language you're using, this causes little problem.
There were even plans for a translator [2] similar to Python's 2to3 tool
Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.
In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.
Also, all the world wasn't unicode at the time and still isn't (unfortunately, IMO, but still the case). We still have customers using various non-Unicode encodings and not all characters have a 1:1 encoding/decoding round-trip through Unicode.
The part about Unicode is about how much Python 2 code accidentally only handled ASCII. Python 2 requires handling other encodings as bytes anyway.
I strongly disagree. I actually tried using unicode correctly in python 2, it is actually quite hard. It's similar to using memory safely in C, it is possible, but there are many gotchas.
In python 3 all of this is done with no effort.
RIP, python2, you will be missed. And a big thank you to all the contributers who have kept it alive for so long!
If at this point you are still stuck on 2.7; you probably don't care a lot about updates in any case; including point releases. It's been well over a decade since it was made clear that this was going to end. So, IMHO the impact to remaining 2.7 users is minimal. They were in any case extremely conservative updating and are probably also running lots of other outdated stuff like Red Hat / Ubuntu versions that long dropped out of LTS, etc. That's fine and valid but at this point you shouldn't be surprised that you are on your own. If you didn't plan for this, that's on you.
From a security point of view that just means you probably don't want to run unprotected 2.7 servers running e.g. a web server. But otherwise it's fine if you shield it a bit. Lots of python is more about other types of jobs where the impact of security vulnerabilities is much less.
And, I'm sure that if there's demand, somebody might actually step up to do the occasional patch release if it is really needed. This has also happened in the Java world where several companies provide support for openjdk 6, 7, and 8 where Oracle no longer supports that (v8 stopped getting public updates already; you can still pay for some extended support but that too is being ramped down). I imagine, e.g. Red Hat might step up here as they seem to have continued to ship this for quite long and their LTS cycles might out run the python 2.7 cut off date.
Python 2 has paid the bills for over a decade, but I love writing Python 3.8 so much more. I even love the walrus operator. We’re in the process of upgrading, finally.
Fix't it for ya.