I’m just starting a GAE app for the first time ever and I chose what you call “old school”, but they call “standard” because my understanding is that it’s more cost effective in that when you have no traffic, you have little to no costs.
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?
I was using GAE Standard with Python on my last gig for a couple of years, and now I'm using GAE Flexible, and I totally agree with you.
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.)
Yeah I'm still using the "standard" GAE, because it's simpler and still has better features -- but old Python :-(. I'm hoping they will eventually upgrade it, but I don't work there, so who knows?
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.
What makes you think GP didn't understand the context? I don't get why people bash other people for saying objective truths just because they think the other person doesn't understand why.
If they can't/won't ship up to date third party software, they shouldn't ship the third party software at all.
Because "lag" implies that Apple is going to catch up, which is not the case. jeremiep's response is that Apple won't ever (under current management) update to GPLv3.
Doesn't imply that to me. To me, lag is just that they're behind, regardless of reason. It is lag and deliberate avoidance. Please stop assuming what people don't understand or are implying.
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"?
From that PEP: It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.
It does. Not sure at what Ubuntu version it happened, but they've transitioned to Python 3 as default. Python 2 isn't even present in a default install anymore.
Guess the community (or a company like RedHat) will have to step in and fork 2.7. There is no way that people who haven't switched, will want to switch, unless absolutely forced to (for example: no security patches).
This old chestnut. Yeah, if there's enough people who are willing to pay for it (time or money), sure, Python 2.7 support will continue.
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.
At some point a CFO will ask why a company is spending $X to use ancient, unhireable versions of their tools when new, free, attractive versions exist. It will be explained - not exactly in these words - that it's basically because their senior devs refuse to learn new stuff. Senior management arguments will ensue. At the end, there will be a plan to save $X with One Simple Trick.
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...
Python 2.7 is currently supported. It's not a great idea, but at least defensible, to still be developing against it today. But the moment it becomes officially obsolete and shops have to justify paying special support contracts to maintain it, I think it'll become very hard to explain why that's a good business decision.
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).
> But the moment it becomes officially obsolete and shops have to justify paying special support contracts to maintain it...
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.
Python 3 has been out since December 2008, so 9 years.
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.
I can see a company providing 2.7 support afterwards. I'm not sure if RedHat, but if there is demand, I totally see 2.7 support as a viable business, at least for awhile.
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.
Like with any other system where some old version just won't go away, the ones who absolutely will not switch to Python 3 will eventually (literally) go extinct.
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).
>Like with any other system where some old version just won't go away, the ones who absolutely will not switch to Python 3 will eventually (literally) go extinct.
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?
At some point in the future the cost of maintenance vs. cost of rewriting/upgrading will be so much in favor of the latter that businesses will make the (correct) choice to "go with the times" instead of spending an ever increasing amount of money and time on maintaining a code base `x` years old written in a language not officially supported/extended for `y` years, experts for which are increasingly rare (and thus expensive).
If they can find Cobol experts 50+ years after the original programs were written, they'll have no issue finding 2.7 experts 50+ years on, especially since 3 and 2.7 and more alike than different.
I expect RedHat to continue to support Python 2.7 for as long as major RHEL versions which came with are still under support.
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.
How many mainstream programming languages do you know having equivalent issues as Python 2.x to 3.x? Do you think it is reasonable to rewrite your code base on every programming language "major version update"? One thing is deprecation of features, because of not thinking an API properly back in the day, and another, involving an important rewrite in order to get your code base working.
My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
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.
In some cases, if they have to break it, they have to break it. CPython developers are notorious for writing PEP and takes so many iterations, debate till end of the world, in order for the developers to accept and publish a PEP.
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.
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.
"The devs are users themselves, and they hate breaking changes too."
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.
Let's take all a minute to thanks the awesome cpython team. Most of the devs work on it for free. They have very little budget as opposed to corporation backed projects like go, c# or js.
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.
My experience over the past year has been that 80% of what I need for new projects is already available on 3 (with the remaining 20% being swappable for other stuff), and that asyncio is a massive (if controversial) boost in performance for some things.
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.
I teach online workshops on intermediate Python to several hundred developers each month, scattered globally. Since these are engineers in the work force, I start each class with a quick poll about which version they primarily use on their jobs: 2.7, or 3.x.
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.
For those still running 2.7 because migrating is too hard, consider using my "ppython" version (https://github.com/nascheme/ppython). It is a modified version of 3.6 with extra backwards compatibility features. After running your code through 2to3, it should mostly work with ppython. After fixing all the runtime warnings, your code should work with regular 3.6.
I took some time try to make an old codebase to work with python2/3. Some wat moment from the effort:
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
I think those are all improvements in Python3, even if they can be a hassle to fix:
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.
71 comments
[ 2.5 ms ] story [ 125 ms ] threadAlso, 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.
Here's a scary case: https://stackoverflow.com/questions/22288604/lambda-function...
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.
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.
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.
[0] https://www.python.org/dev/peps/pep-0394/
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 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?
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.
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.
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?
Already done: https://github.com/naftaliharris/tauthon/
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.
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.
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.
http://stfupy3.org/
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.
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:
3. You can do `def foo(a, (b, c), d)` in Python2: https://www.python.org/dev/peps/pep-3113/4. You can compare slice with int in Python2:
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 hope macOS get onboard next year also...