Python 2.7 Countdown
pythonclock.org
pythonclock.org
Yet.
The language has helped us since 5 years before java was born. You can find it in websites like youtube and instagram, OS stacks like linux and mac, wall street and NASA analytics, popular GIS, dropbox UI, blender and maya, sublimetext...
Also thanks for having provided almost 15 years and many tools to migrate from 2 to 3. I know few languages that managed such a big update, but none that gave so much to help with the transitions.
Guys and gals, you rock.
And it needs to be said because we hear the people complaining the most loudly. Never all the people that are so grateful for it.
18 months ago, the results were typically 20% Python 3, and 80% Python 2. Over time, the ratio shifted. In recent months, it's VERY consistently 60-70% Python 3; one class it was 80%.
As I tell those students: sooner than you think, having only Python 2 on your resume will make it look dated.
You're taking what I wrote too literally, and thus missing the point. What I wrote means: if the only Python you know is 2.x, it might close off opportunities for you in the near future.
1. `StringIO.StringIO` is a PITA. There's no equivalent in Python3 (for a good reason), and you must choose between `io.StringIO` (which only support unicode) and `io.BytesIO` (which only support bytes string). A possible solution is to use `six.StringIO` but it's simply bury the problem. It would be a good idea to think about what string you are dealing with before doing any change around StringIO.
2. The `stat` module contains some helper functions to test st_mode. In Python2, the function will happily accept negative numbers but in Python3 an exception will throw:
$ python2 -c 'import stat; print(stat.S_ISDIR(-1))'
False
$ python3 -c 'import stat; print(stat.S_ISDIR(-1))'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OverflowError: can't convert negative value to unsigned int
4. You can compare slice with int in Python2:
$ python2 -c 'print(slice(1) > 1)'
True
$ python3 -c 'print(slice(1) > 1)'
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: unorderable types: slice() > int()1. Lots of legacy code incorrectly treats strings and byte arrays as the same thing. If you're dealing 100% with all ASCII all the time that might be mostly OK, but it's the wrong model for anything involving Unicode (which is pretty much everything now).
2. Modes are defined on Linux and macOS at least as uint32_t. -1 isn't a valid value of that type.
3. That bit me a few time. I've accepted that `def foo(a, b_and_c, d): b, c = b_and_c` is an alright substitute.
4. I like the new version better. `'a' > 5` doesn't even make sense and the 3.x way avoids accidental nonsensical comparisons.
I do wish that some of the gevent/Cython stuff was 100% compatible on occasion, but it's manageable.
That said, 2.7 is still the default in many environments, and we're likely to have to live with it for 12+ years.
Also, standard has start up time of like a second vs minutes for the “flexible” version. Basically standard, with Python 2.7 is a true app engine, where flexible is just a container service which runs almost whatever you want.
People really shouldn’t try to position flexible as a new version of GAE. It’s a totally different service. If everyone who’s currently using standard had to switch to flexible, Many if their bills would go up. Is Google EOLing standard?
My guess have always been that the naming choice was an attempt at rescuing the somewhat bad PR they had with GAE Standard by "polluting" (improving) the GAE brand with this new thing.
(I was seriously concerned when I was told during the interview that they were using GAE on this job, but reliefed when it turned out to be GAE Flexible. However, I do miss some of the magic provided by Standard, but do not miss Python 2.7 and some of the restrictions.)
Perhaps it's that ominous counter, but these words really evoked Poe's "The Masque of the Red Death" for some reason.
In "The Masque of the Red Death" they shut themselves away from the rest of the world. There's no correspondence from that to the end of core developer supported Python 2.
I just hope those same people have used the past years to do calculate the cost of moving to Python 3 vs the cost of Python 2 support. Expecting Python 2 support to be free or even easy is delusional/selfish though.
Expecting that everyone will just hop over Python 3 because one group of people doesn't want to maintain Python 2 anymore is delusional.
Displaced senior devs will find themselves making nice paychecks at other shops with obsolete codebases, at least until those CFOs start to notice a funny line item in the engineering budget...
None of this has happened yet.
What is going to make 2.7 so unmaintainable? It’s there, it works and what is going to change that?
It's easy to forget that Python 2 was supposed to have been deprecated in 2015, but that got pushed back until 2020. Personally, I don't feel like backporting security fixes forever.
There are valid reasons for using 2.7 today. I think it's professional negligence to not at least be planning for the inevitable upgrade to the current version. Honestly, it's almost never as hard as you'd think. The most common hurdles are str/bytes incompatibility, and 3.x only reveals those problems where they already exist in 2.x (where the code is quite possibly not working as expected but silently passing wrong data without warning you).
Who even pays for a support contract for programming language that’s already done?
That’s like saying JavaScript is unusable because of all of the different versions. Nobody has to pay anybody to use ES3 even though it’s largely obsolete.
I think it's unlikely that the community will bring support. Most of the community already jumped to 3.x, and those who haven't will do in the next two years. Also, supporting legacy code is not something that volunteers love to do.
And this is perhaps the Achilles heel of FOSS in the long run...
What we can do, as the people who live in the present, is educate programming/python newbies to use the newer/better Python 3, instead of clinging to something that will soon lose official support (for AFAIK good reasons).
And yet there are tons of lines on COBOL in active use today. What makes you think 2.7 code, which powers tons of businesses, is going anywhere?
I also expect major RHEL versions released after Python 2.7 is EOL to not come with Python 2.7 anymore.
That is, if RHEL 8 is released before the Python 2.7 EOL, and RHEL 9 is released after the Python 2.7 EOL, I expect RHEL 8 to come with both Python 2.7 and Python 3, with RedHat supporting both until RHEL 8 support ends, but RHEL 9 to come with only Python 3; so once RHEL 8 dies, RedHat has no reason to support Python 2.7 anymore.
Starting from 17.10, Python3 is the default one and the preinstalled one.
This switch kind of happened unnoticed because Ubuntu switched back to GNOME at that version, but IMHO it is an equally important switch.
With 18.04, we should see that change having much greater effect.
I don't get why people bash things when they clearly don't understand the full context (pun intended ;)
If they can't/won't ship up to date third party software, they shouldn't ship the third party software at all.
It's not a lag, it's a deliberate avoidance.
OpenSSL is not GPL3. They still shipped a very old version, then apparently switched to LibreSSL... and promptly shipped an old version of that.
They lag. Licensing is an issue for a subset of tools, but lagging is very much an issue for all of them.
In the most recent Vendée Globe around-the-world sailing race, 11 people did not finish. https://en.wikipedia.org/wiki/Vend%C3%A9e_Globe#2016%E2%80%9... . Do you say they are lagging?
Some people start to hike the Appalachian Trail, stop part-way through, and decide to move to/live where they stopped. They never finish the trail. Are they lagging?
Why do you assume that you know what toyg means by "lag"?
OpenSSL is not GPL3. They still shipped a very old version, then apparently switched to LibreSSL... and promptly shipped an old version of that.
They lag. Licensing is an issue for a subset of tools, but lagging is very much an issue for all of them.
Here's a scary case: https://stackoverflow.com/questions/22288604/lambda-function...
I do hope macOS get onboard next year also...
That's what a major version update is.
My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
It will be backward compatible (unless there is an absolute need to break), but just keep Python 4 out of your head. For now, they predict just 3.10+
So when someone has to decide between language X and Y, with the risk of another Python 2.x to 3.x "drama", that argument would be an important point for picking one language or another.
For long term decisions "predictions" are a risk, i.e. not committing in backwards compatibility. Commitment reduces the risk. I asked for commitment not because of "purity" but because of the risk.
P.S. I like Python. What I don't like is the 2.x to 3.x transition, and the risk of happening a similar thing again.
While I do not speak for any of them, what the blog post is trying to say is they have made a mistake with the 2 to 3 transition by introducing so many breaking changes. Instead, they have acknowledged this mistake, and will work very hard to not break anymore. But they also want to reserve a tiny room so they are not called "you lied to us!" Perhaps some fundamental change has to be made.
If there is one person who hates breakage, it will be Linus.
See http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
He made it clear that over the years, there has been very few exceptions allowed. On the contrary, he mentioned that kernel internal APIs are fine to break.
What we want to achieve in general, according to Linus, is avoid breaking user APIs (or userland in Linux). But rest assure, when some new language feature added, or changed, or broken in CPython, you can expect a PEP.
Lastly, you still have the option to send the devs (including Guido) an angry email on python-dev :-) The devs are users themselves, so I am sure they are sympathetic with the pains in the 2-to-3 transition.
Sure. That's the point: e.g. back in the day UTF-8 was invented for allowing Unicode support without breaking API compatibility. I ask for thinking 10.000 times before breaking backwards compatibility.