> Anybody has a reasonable theory for why this took so long, despite users asking for it for years?

Well, initially, their investment in more runtimes was covering additional languages, not covering more versions of languages they already had. (IIRC, AE started with Python 2, added Java first, and then later Go and PHP.)

As that was happening, they gradually shifted focus from building out the old, fairly limited model of App Engine to building out other parts of the cloud platform, including (particularly relevant to future App Engine work) Compute Engine, to have a more robust cloud offering covering more use cases.

Then, they went back and returned to improving App Engine -- leveraging the now-broader cloud platform, and particularly Compute Engine -- shifting from the old model for new runtimes to the Flexible Environment (originally called "Managed VMs") model (built on Compute Engine, and which, in addition to including some additional Google-provided runtimes, means people can package up their own runtimes for App Engine).

Since doing so, they've released official Google runtimes for Python 3, Ruby (which people have been asking for longer than Python 3), and Node built on the Flexible Environment.

The architectural switch to the "Flexible Environment" is what I missed. I can appreciate why this broader new approach for language runtimes took some time.

But then again the Flexible Environment seems to be a very different product with different features/characteristics and pricing than what I once knew as "App Engine". I would then argue that Python 3 never came to "App Engine", only to their new product. Which is a valid strategy for Google of course, but now stifled my enthusiasm. Probably I only need to learn more about Flexible Environment style App Engine to become hyped again.

Flexible environments are significantly worse if your application works on the original style of app engine.

Just wondering, why do you think so?

(It wasn't obvious to me why, given a first read of the docs; the fact that applications run in VMs in Flex seems more like an implementation detail. Am I missing something?)

We use both and try to stick with standard runtimes wherever possible, resorting to flexible runtimes for things doing heavier processing and/or with lots of instances.

The standard runtimes are superior in a lot of ways, two big wins being lightning fast deployments (seconds vs. many minutes) and batteries included for all the app engine services. Logging in the flexible environment can also be a bit lacking. When you have something running in standard runtimes you basically don't have to think about many of the things that can normally go wrong on a server.

That said, many things about the flexible environment are rapidly improving, they've certainly come a long way since we first started playing with them around 6 months ago.

Especially amusing was that Guido was working on the GAE team for a while, and even that wasn't enough to get them to support Python3.

I wouldn't say amusing, though it is interesting, and taking note of Go and Dart, it may reflect what role Google thinks Python plays.

I assume that was depressing.

I think this is my main problem with Google services. It takes them forever to listen to people. And I don't think other cloud services listen any better but at least it seems they give you what you want faster. So they have a better mechanism to know what works and making a product of it.

I think you misread it. Unfortunately it looks like Python 3 is not going away. You did say big fat blemish, right?

I think the "lack of Python 3 support" is the blemish referred to, not Python 3 itself.

I think you may have missed the sarcasm in the parent post.