Google is working on Python 3 for App Engine Standard Environment

Feature development of GAE (especially the Standard Environment) never stopped. Some of the features require multi quarters of work (e.g. https://cloudplatform.googleblog.com/2018/05/Increase-perfor...), some are more enterprise-focused, some are not user visible but we improve the reliability with a new stack behind the curtain. We are changing the engine while flying (pun not intended).

For various reasons, supporting new runtimes was never an easy task, even for small version bumps. This has changed drastically, starting with Java8 runtime, to the recently announced NodeJS beta, and to the closed alpha of Python 3 (remember this is Python 3.7). If you followed recent announcements from Google you probably can connect the dots.

I think we are pretty open on what we are working on to our customers, as long as an NDA is signed. If you are interested be sure to let our cloud support team know!

Disclaimer: I'm on App Engine SRE team.

The Google career page (1) indicates that they are hiring a lot of people in that area, so we might see some fast paced improvements there.

1: https://careers.google.com/jobs#t=sq&q=j&li=20&l=false&j=clo...

What have AWS dropped RE Amazon Linux 2? (I thought python 3 was supported there via Amazon Linux Extras.)

tl;dr Standard environment apps "scale nearly instantaneously to handle huge traffic spikes", "cost-effective for applications that have significant periods where they are not serving traffic", use reasonably limited standard API + proprietary API

It will likely remain around for longer, since depending on unsupported software doesn't immediately kill a project. When old Python 2 code hits a bug in the CPython interpreter and nobody is around to fix it, there'll finally be an incentive to migrate away (maybe to Python 3, maybe to another language), but not before that.

I wouldn't be surprised that vendors will still have to do the fixes to Python 2 for many years past that date, and that a kind of "fork" will keep the 2.7 branch decently alive much longer. It's just the current "official" maintainers that announce the cutoff date for their work.

The PSF might be trying to murder Python 2, but it can't do it any more than GCC could kill c99 for c11.

I look forward to using c99 and Python 2.7 for many years to come. There are more then enough Companies and Devs to keep Python 2 ticking over forever.

Doesn't mean that python 2 programs will stop working. I know developer of Calibre has stated that he will maintain the python 2 codebase himself. And is actually happy that python 2 development will be out of the current maintainers hands.

I like to remind people that Python 3 was already more than a year old when Apple announced the first iPad. I'm not sure anyone should be getting a cookie for 'working on' Py3 support more than nine years later. Though I do understand that GAE has supported Py 3 for a while in its more configurable service.

To be fair: PEP 3333 that addresses WSGI support with Python 3 Unicode was initially drafted in September 2010. I would consider that to be the first day we can write a web server in Python 3.

> the difference is between Docker and Google App Engine

Neither the question nor the answer in your link compare Docker and App Engine.

Docker is a containerization platform, whereas App Engine is a PaaS (platform as a service). Their functions are wholly different.

Very, very loosely; Docker is about building and running an individual package of some software. Basically, bundling software and running bundles. PaaS are platforms for developing, running, and managing (often pre-bundled) software.

Python 1 didn't know about Unicode, so characters were bytes and things were simple (for latin1 users).

Python 2 bolted on Unicode support, so now you had two kinds of strings (old-style strings and Unicode strings) with implicit conversions between them (that would blow up spectacularly when you least expected it) and overall a huge mess.

Python 3 removes the old-style strings (replacing them with the "bytes" type and explicit conversions), so that we once again have only one type of string, and once again things are simple. This clean-up unfortunately means that code relying the Python 2 string type confusion will break.

The transition from Python 2 into Python 3 was badly botched, and for many years. First of all, they confused language with implementation, so the Python 3 interpreter cannot handle the Python 2 language while the Python2 interpreter cannot handle the Python 3 language (I refer to the main C interpreter, not others like PyPy). The automated tool "2to3" wasn't reliable on real-world programs, either. For many years it was impractical to write programs or libraries that worked on both 2 and 3. To write any Python 3 code, ALL of your transitively-dependent libraries had to convert to Python 3, and effectively simultaneously. By itself, that was rediculous. In addition, Python 3 doesn't add any radically new capabilities over Python 2, so it was basically all pain and no gain. Python 3's new approach to strings is conceptually clean, but it struggles with the messiness of the real world and the Python 3 developers had to add a lot of hacks to make it sort-of work. For example, file names are not strings of characters on Unix/Linux, there is no standard encoding for stdin, and real-world data doesn't always follow any particular encoding and there's often no need to require it. Python 3 was effectively ignored by most programmers for at least 5 years after its release, because it created more problems than it solved.

What changed is that Python 3 was modified, and libraries were added to both Python 2 and 3, so that it started to became practical to write code that could work on both 2 and 3. The result: instead of having to transition your entire program and all its dependencies simultaneously, people could work incrementally, making little improvements here and there so that programs would keep working in 2, and eventually work in 3 as well. Various hacks were also created so that Python 3 could handle stuff like filenames (!).

It would have been much better had the Python 3 developers made it easier to transition from 2 to 3 from the start, but it's finally easier. It's still somewhat painful; mercurial still hasn't transitioned, and it's not clear that they ever will. I'm unhappy about what the Python developers did earlier, but I think they've made good strides in trying to finally make it much easier to transition from Python 2 to Python 3.

The main takeaway here should be, "make it as PAINLESS as POSSIBLE for your existing users to transition to a new version". It's okay to change APIs, but use different names or use versioned APIs. It's okay to change other things, but make it easy for people to modify parts of their program at a time. You'd think that'd be obvious, but it's clear that really smart people don't always think about that.

Other languages rarely have backwards incompatible changes. C or C++ from 20 years ago would still compile perfectly fine with modern compilers.

As far as I know, Go, Java, C#, C++, C and Javascript have never broken backwards compatibility.

Python 3, and Perl 6 did. I don't think anyone uses Perl 6.