Python 3.7

When will Python 3.7 be available on here?

3.7 is still in beta, but we're planning to get a new system image together reasonably soon; it will have updated versions of Python.

Now that 3.7 is released, when can we expect a new image?

It's on its way; we have one built and in testing, but there are quite a lot of tests we need to do before we can release it. It will definitely be in our next system update, though.

And when?..

Should be ready in ~ a week's time.

Not to be pushy, but.... Python 3.7? ;-)

Heh, good timing :-) It's been live for a little while now for newly-created accounts, and we were planning to do an official announcement on the blog tomorrow.

Adding Python 3.7 to your account does require upgrading your system image, though -- the new image is called "earlgrey" (after the previous system images, "classic" and "dangermouse"). What this means is that the pre-installed Python packages will all get upgraded, which means that any code you have that depends on them might stop working if it's not compatible with the new versions.

For previous upgrades, from classic to dangermouse, we said that all was OK if you were using a virtualenv, which (of course) removes the dependency on the pre-installed Python packages. However, this new image not only adds Python 3.7 and upgrades packages, it also upgrades the older Python versions -- for example, from the antediluvian 2.7.6 to 2.7.12, and from 3.6.0 to 3.6.6. This can break virtualenvs in some cases.

So, long story short -- we can certainly switch your account over to the new system image, but you may need to rebuild your virtualenvs afterwards if you're using them -- and you may need to update your code to handle newer pre-installed Python packages if you're not using virtualenvs.

There are more details about exactly which package versions are included in which system image on the batteries included page. And if you'd like to switch your account over to earlgrey, just drop us a line using the "Send feedback" button. (If you've read all of the above, and understand that you may have to make code/virtualenv changes, mention that you have in the feedback message as otherwise we'll respond by basically repeating all of the stuff I just said, and asking "are you sure?")

Resurrecting this somewhat: I've got all my code in virtualenvs so I got that bit covered. Rebuilding virtualenvs; is it as simple as deleting the old ones, creating new and 'pip install requirements.txt' and referencing the new ones under the web tab?

python relase their new version 3.7.0 on 28-6-2018 and they currently work on 3.7.1 version of the python features in the 3.7.0 update 1.PEP 539, new C API for thread-local storage 2.PEP 545, Python documentation translations 3.New documentation translations: Japanese, French, and Korean. 4.PEP 552, Deterministic pyc files 5.PEP 553, Built-in breakpoint() 6.PEP 557, Data Classes 7.PEP 560, Core support for typing module and generic types 8.PEP 562, Customization of access to module attributes 9.PEP 563, Postponed evaluation of annotations 10.PEP 564, Time functions with nanosecond resolution 11.PEP 565, Improved DeprecationWarning handling 12.PEP 567, Context Variables 13.Avoiding the use of ASCII as a default text encoding (PEP 538, legacy C locale coercion and PEP 540, forced UTF-8 runtime mode)


Bump for my question above: after the switch, if there are packages in the old virtualenvs, is rebuilding them as simple as deleting the old ones and creating new ones + pip install + referencing the new ones under the Web tab?

Thanks in advanced.

yup! you would have to do it for all virtualenvs (because the pythons the virtualenvs were symlinking to would be broken)

if you create the new one with the same name and path, you could probably just reload the webapp without changing the virtualenv config on the web tab.

and if you do anything to customize your virtualenvs (eg: pre/post hooks), you may need to make sure you set them up again