
Google is working on Python 3 for App Engine Standard Environment - ognyankulev
https://issuetracker.google.com/issues/35876441#comment104
======
privateSFacct
I never get this about google. They had a great product here (I and I know
others actively interested) but they just drop development on these things for
the new shiny toy. We're not asking for a ton, but if you could assign even a
few folks to maintain the non-cool stuff, I think a lot more folks would build
on GCP.

I'm on AWS currently. They keep their old / uncool stuff around in a nice way
(and totally seem to drop ball on other stuff that matters less like their new
Amazon Linux 2 effort - python 3 support in that is totally wonky etc).

~~~
yegle
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...](https://cloudplatform.googleblog.com/2018/05/Increase-performance-
while-reducing-costs-with-the-new-App-Engine-scheduler.html)), 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.

~~~
mijamo
I mean things have been pretty bad for GAE standard in Python for a very long
time. It looks so dead I was actually expecting Google to completely remove it
in 2 years or so.

I work on a project on GAE standard and the platform was chosen before I
started. I would say this was the worst possible solution to chose and the
biggest cost for us right now.

The most annoying point is that it is actually not easy at all to switch to
the Flexible environment, because libraries are completely different.

Examples of troubles : \- new google-cloud libraries run in the flexible
environment but not in the standard one (ex: google-cloud-pubsub doesn't run
in the standard env after 0.27, and the doc for 0.27 is dead: [https://google-
cloud-python.readthedocs.io/en/0.27.0/pubsub/...](https://google-cloud-
python.readthedocs.io/en/0.27.0/pubsub/index.html)) \- traditional standard
env libraries do not run in the flexible env. The most typical example is NDB
for the Google datastore.

Which means that migrating from the standard to the flexible env requires you
to rebuild EVERYTHING that touches Google services... Great, then I'd better
just switch to AWS instead!

What's moer, flexible env is nice but for some reason it is not possible to
have basic scaling anymore, nor is it possible to scale down to 0 when needed,
which makes modular apps much more costly (previously we would have several
services and when unused they just scaled down to 0).

On top of that we just watched services get deprecated one after the other
(mail service, then the datastore backup etc.) and old troubles not getting
fixed (like memory problems with queries).

~~~
yegle
The technique behind standard and flex is large enough that we simply cannot
provide consistent experience between these two. In fact these two products
are supported by different teams. While the inconsistency is unfortunate, we
are fully aware of this issue and are working towards a solution. Please
expect some announcements from us.

Service deprecation is not taken lightly, and we guarantee 12 months per GCP
deprecation policy
([https://cloud.google.com/terms/deprecation](https://cloud.google.com/terms/deprecation)).
Of the services you mentioned, I don't think mail API is officially deprecated
(per
[https://cloud.google.com/appengine/docs/deprecations/](https://cloud.google.com/appengine/docs/deprecations/)),
and Datastore Backups is superseded by Managed Export
([https://cloud.google.com/datastore/docs/export-import-
entiti...](https://cloud.google.com/datastore/docs/export-import-entities)).

Not sure about the memory problems you mentioned though.

Disclaimer: I'm on App Engine SRE team.

------
berti
For anyone confused, currently you have a choice of either "Standard
Environment", which is Python 2.7 only, or "Flexible Environment" which allows
you to choose Python 2.7, Python 3.6, or your own Python runtime [1][2]. This
is about supporting Python 3 in the "Standard Environment". It's unclear
whether the intention is to replace Python 2 or allow a choice?

[1]
[https://cloud.google.com/appengine/docs/python/](https://cloud.google.com/appengine/docs/python/)
[2]
[https://cloud.google.com/appengine/docs/flexible/python/runt...](https://cloud.google.com/appengine/docs/flexible/python/runtime)

~~~
ognyankulev
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

~~~
dudus
More importantly standard scales down to 0 while flexible needs a minimum of 1
instance running at all times. So when just prototyping/developing or creating
a small app only you or a few users will use it's very cost effective to use
standard.

------
Godel_unicode
Reminder that Python 2 dies in 18 months.

[https://pythonclock.org](https://pythonclock.org)

~~~
CJefferson
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.

~~~
pjmlp
GCC and clang are probably the only C compilers in the world that care about
C11, so it is quite hard to kill C99 for C11.

~~~
CJefferson
True, but following the Python model, GCC and Clang could just threaten people
with the death of C99 for 5 years or so, then in some release just disable
them.

Of course, that would be much less painful than Python 3, because C11 is (a)
almost entirely compatible with C99, and (b) not noticeably slower.

~~~
pletnes
AFAIK python 3.5 and 3.6 are significantly faster than 2.7 and uses less
memory due to dictionary optimizations. I don’t think speed has been a real
argument in a while. Also, python 3 is almost entirely compatible with python
2 (although C is probably even more so).

~~~
newen
Everyone would have migrated to python 3 years ago if it was almost entirely
compatible with python 2. It's just not.

------
cheriot
I love the new movement in on GAE Standard. With GAE Flexible, GKE, Cloud SQL,
etc there's actually a growth path for something that out grows it. When
Standard first launched, that additional complexity meant a rewrite.

Can the Java runtime implement the full Servlet 3.1 spec now? It's 5 years old
(and most Scala http libs don't support blocking Servlets anymore).

------
shaohua
at 10 years birthday of app engine and 10 years birthday of python3

~~~
sago
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.

~~~
raverbashing
True, though I have to say it only got usable around 3.4 (which still is 4y.o.
at this point)

~~~
sago
What did 3.4 give you that 2.7 already had? I have found bundled pip and
asyncio useful, but I was using Py3 from 3.2, successfully. It didn't suddenly
become usable at 3.4 for me.

~~~
toyg
I think what happened was that 3.2 was the first "real" release, when a lot of
.0 bugs were shaken out; the 'u' prefix was added back around that time too,
iirc.

This resulted in more developers actually porting their libraries, an effort
that had been basically non-existent before. The result was that the 3.4
ecosystem actually got mature enough that Real Work could get done, and more
end-users started moving.

IIRC 3.3 also had some big performance problems that were sorted in 3.4, but I
cannot remember the details.

Personally, I did very little with 3.2 but actually built Real Stuff only with
3.4.

------
savrajsingh
Appengine standard is amazing. I hope they continue to support 2.7 as well.

------
mikece
Just in case you're like me and had to Bing what the difference is between
Docker and Google App Engine, it's summed up really well in this Stack
Overflow answer:

[https://stackoverflow.com/a/49950687/3799](https://stackoverflow.com/a/49950687/3799)

I wonder, though, if future development should target Docker/K8S and GAE
should only be the domain of legacy applications.

~~~
deklerk
> 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.

~~~
mikece
Would it be more accurate to compare Google App Engine (PaaS) to Azure Web
Apps or App Service (also PaaS)? Docker is in a weird spot of not really being
PaaS but yet too light to be considered IaaS... I tend to think of it as
sufficiently PaaS-like except it runs on everyone's cloud as well as my
laptop.

------
oooooof
Google also committed to releasing an update to its App Engine Gw Basic and
Turbo Pascal environments, “some time in the 2021 timeframe”.

------
olskool
I tried Appengine when it first came out but Google never seemed to support it
much so I gave up on it.

------
k__
What lead to this whole Python 2 and 3 divide?

I mean, other languages have new versions too...

~~~
ptx
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.

~~~
k__
Well, at least someone tried to clean things up.

Other languages simply carry these bugs around forever.

------
IshKebab
Yet another example to throw in the face of people who say that the Python 2/3
problem is solved.

