Python 2.7 Retirement Countdown
pythonclock.org
pythonclock.org
My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years.
I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.17.
I'm probably in a special area -- algorithms research. I tend not to use many libraries, and I'm often taking code written 10-20 years ago and wanting to get it working. The code is often VERY complicated, and I don't really want to reimplement it.
Finally (and probably most importantly) I don't care about security holes, I'm not going to run this code on malicious input.
Conversely I'm always behind on Node as it's realllly annoying when a third-party lib breaks from an update. Larger packages will be fine but when you're dealing with say a Meteor package derived from an NPM package it's pretty shitty.
Would you want the world to still be using K&R C? Because I remember the transition from that to ANSI C, and the special macros to make function prototypes work across both languages. The Python transition is little different.
Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.
The old meme that it's unsafe to use Py3 is not true anymore. Practically all of the big libraries work fine on Python 3 now. Py3 code is going to be dominant in new projects in short order if it isn't already, and it's plausible that new Py2 projects will be virtually extinct by 2020.
What are they using it for?
Python should've abandoned and deprecated 2 ages ago. I still see new tutorials teaching 2. What the hell.
...and honestly, whats wrong with that?
really, what difference does it make if people use old python versions?
Other than the core python team, which get to be embarrased that many people have zero interest in the work theyre doing?
Does it affect you? nope. Does it break the ecosystem? nope. Does it make library authors suffer? nope (dont support it if you dont want to).
Come on. Live and let be.
If you love python3, use it. Dont winge pointlessly (not you personally; all the hostile frothing at the mouth python3 advocates, especially on reddit)
I guess you can decide for yourself if the 'official support' of python is a massive drain on resources that could be used else where.
(The red line with a few commits now and then is the 2.7 branch)
I really don't know where else you think those resources could have been used that wouldn't have resulted in Python 3. Unless you consider "doing nothing meaningful" to be a form of support.
Also python 3 support is increasing, while python 2 support is decreasing overall https://blogs.msdn.microsoft.com/pythonengineering/2016/03/0...
It shows MySQL-python as 3.0 ready, but MySQL-python page (https://pypi.python.org/pypi/MySQL-python/1.2.5) notes:
> MySQL-3.23 through 5.5 and Python-2.4 through 2.7 are currently supported. Python-3.0 will be supported in a future release. PyPy is supported.
They have overridden mysql-python with mysqlclient https://github.com/PyMySQL/mysqlclient-python
I am aware of this, but the fact that the tool is reporting MySQL-python as 3.0 compatible, when it is not, is worrying.
Did the parameter names to open()d really need to change? Why did I have to change from io.open() to open() for a stream? Did str.lowercase really need to become string.ascii_lowercase? The number of errors in my toy little program upon upgrading really surprised me.
But to keep Python improving without weighing itself down, some changes couldn't just be slipped into the 2.x series. Because they're fundamental enough changes to even effect toy programs.
So, yes, I'd say that the default string type did need to change from bytes to unicode. And not only do I not miss str.lowercase, that kind of vestigial feature is exactly the type of thing that should be purged with the unicode transition.
Is it too late? Can we back out of the current incarnation of Python 3 and go down another path instead? In other words, turn the slow adoption rate into a plus, call a do-over and mold the new Python into something more people are happy with.
After so many years, why the resistance?
Python 3 has the subTest context manager (which looks great)
https://docs.python.org/3/library/unittest.html#distinguishi...
In 2.7 you must use pytest, ddt, nose-paramemterized or dynamically add test methods to a TestCase class at runtime.
Putting that aside, my issue with 3.X is that I have to use the unicode type even when I'm manipulating byte strings.
What? No you don't. The `bytes` object is what you want when you deal with byte strings.
Not to mention all the b prefixes it just becomes painful.
Get off your high horse and upgrade your code. So many people did it before you, and so can you.
This is an old pointless fight. :/
Yes, you can add anything without breaking backward compatibility. That's why I qualified it with "reasonable" -- there are very good reasons to break backward compatibility, and being a slave to it will pile up technical debt in very unpleasant and potentially avoidable ways.
It's like trying to make a skyscraper taller without rebuilding the foundation. Sure, you can add giant ugly supports on the side, but once you've done that a few times, nobody is going to feel safe near your building. And no self-respecting architect would do it.
You've to be quite naive to believe that Python 2.7 will retire in 2020. It will only fade from popularity slightly faster.
See also: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
They're going to do what's pragmatic and cost efficient. Making everyone stop improving the product and porting the code base, is probably more expensive than just having one team maintaining and improving the interpreter.
At this point, the chicken-and-egg problem has effectively been solved for Python 3. Practically every major Python library has Python 3 support these days. The mainstream Linux distros are switching to Py3 as the default this release cycle. The largest remaining holdout will probably be PyPy diehards, but 3 years is a long time and I'm confident that the community's increased interest in Py3 will be made manifest to the PyPy development team in the not-too-distant future.
I believe that the posted site is correct, Python 3's time is now. While there probably will be a fork specifically intended to provide security backports for legacy applications, I don't think it will see widespread use (the people who continue to run Py2 applications at that point will probably keep running the never-to-be-updated again CPython runtime).
The people who are still using Python 2 are the 'lazy' ones, who don't really care about the community at all; the ones who keep making comments like 'I just use whatever the `python` command starts.' I'm pretty sure these people couldn't maintain Python 2 by themselves.
I haven't actually checked, it could probably be ported now - but why would you do that now - everything can change in the next 3 years.
There two things that might help you port things:
1. You can use Cython to mix python 2 and python 3 code together. You compile python2 code as a module and then reference it from the python3.
2. MyPy (http://mypy-lang.org/) - This might not seem like related, but if you provide information about types refactoring the code becomes much easier (like in statically typed languages) so when you change something it's easier to find all other places that also need to be changed. Some IDEs (for example PyCharm) also understand typing which helps when using their refactoring functionality.
(Disclaimer: I am not supporting any side)