The Python 3 runtime on App Engine standard environment is a second generation runtime. The use of a new sandboxing technology enables this runtime to support a fully idiomatic Python development experience.
Idiomatic Python development experience
The Python 3 runtime is built around three core ideas:
- Your app uses the latest version of the open source Python interpreter provided by the Python Software Foundation.
- Python's rich ecosystem of packages and frameworks, including those that use C
code, can be deployed alongside your app using a
- You don't need specialized, platform-specific knowledge to develop on App Engine.
The overall goal is that your app should be fully portable and run in any standard Python environment. You write a standard Python app, not an App Engine Python app. As part of this shift, you are no longer required to use proprietary App Engine APIs and services for your app's core functionality. At this time, App Engine APIs are not available in the Python 3.7 runtime.
Migrating between Python 2 and Python 3 on the App Engine standard environment
The Python 3 runtime on the App Engine standard environment is significantly different from the Python 2 runtime. The following sections provide additional details on differences between the Python 2 and Python 3 runtimes, as well as as recommendations on how to approach these differences when designing your application.
If you decide to migrate your application from Python 2 to Python 3 on the App Engine standard environment, you should be aware of the following differences:
- Compatibility issues between Python 2 and Python 3
- Fewer restrictions on the runtime environment
- No App Engine APIs, changes to app.yaml, and local development
We will share additional updates to the migration path as the updates become available.
When Python 3 was first announced in 2009, a number of
backwards incompatible changes
were introduced to the language. These changes range from easily manageable
such as the
print() function to more
complex, for example, text, string and binary data handling. Additionally,
many popular open source libraries, including the Python standard libraries,
have undergone changes as they have moved from Python 2 to Python 3.
There are numerous online guides that can help you navigate these changes. Tools can help you manage automated Python 2 to Python 3 code translations. The Python community has provided ample resources to help manage these changes. They are thus not covered in detail in this document.
The Python 3 runtime has fewer restrictions than the Python 2 runtime. You can now install arbitrary third party dependencies, access the file system, spawn background threads, and use Google Cloud client libraries.
Third party dependencies and native code
install arbitrary third party dependencies,
including those that use native code. App Engine will install
dependencies listed in the
requirements.txt metadata file using the command
File system access
Files can be temporarily written to
/tmp. Note that files written to
/tmp may not be available across subsequent requests to your app.
Python 3 in the App Engine standard environment has no sandbox limitations so you are free to create threads or processes that live outside of the request environment. Threads and processes can be spawned using Python's built-in threading and multiprocessing features. However note that new threads or processes may not run after the inbound request is served.
Cloud Client Libraries
libraries are supported on this runtime. You can use these libraries to access
Google Cloud Platform services such as Cloud Pub/Sub, Cloud Datastore,
Cloud Spanner and others. You can see the full list of supported products on the
The Python 3.7 runtime in the App Engine standard environment does not use the App Engine SDK to provide access to service functionality, unlike the Python 2.7 runtime, which does. Instead when using the Python 3.7 runtime, you should use the Google Cloud managed services and/or third party services that meet your needs.
Changes in this section refer only to Python 3.7. The Python 2.7 runtime remains unchanged.
The behavior of some fields in your
app.yaml configuration file has been modified.
|entrypoint||Added||Adopted from the App Engine flexible environment. You may, optionally use this field to specify the command that will run when your app starts.|
|threadsafe||Deprecated||All applications are presumed to be threadsafe.|
|api_version||Deprecated||No longer used in the Python 3 runtime.|
|libraries||Deprecated||Arbitrary third party dependencies can be installed using a |
Use of any of the deprecated fields returns an error when you deploy your app.
appcfg.py are not supported for Python 3.7. Use the
command line tool to deploy your app.
App Engine APIs
Proprietary App Engine APIs are not available in Python 3. This section lists recommended replacements.
For an alternative to a NoSQL key/value database like the Datastore API, use Cloud Firestore. When you create a new Cloud Firestore database, you can configure the database instance to run in Cloud Datastore mode which makes the database backwards-compatible with Cloud Datastore.
For more information, see Choosing between Native Mode and Datastore Mode.
To build an application cache, create a Cloud Memorystore instance and connect it to your app using Serverless VPC Access.
Use a combination of environment variables and the App Engine Admin API to obtain information and modify your application's running services:
|Service information||How to access|
|Current service name||
|Current service version||
|Current instance ID||
|Default hostname||Admin API
|List of services||Admin API
|List of versions for a service||Admin API
|Default version for a service, including any traffic splits||Admin API
|List of running instances for a version||Admin API
Host any full-text search database such as ElasticSearch on Compute Engine and access it from your service.
Queue tasks for asynchronous code execution using the Cloud Tasks REST API, RPC API, or the Google Cloud Client library, and use a Python 3.7 App Engine standard service as a Push target. For more information, see Migrating from Task Queues to Cloud Tasks.
In many cases where you might use pull queues, such as queuing up tasks or messages that will be pulled and processed by separate workers, Cloud Pub/Sub can be a good alternative as it offers similar functionality and delivery guarantees.
For an alternative to the Users API, use any HTTP-based authentication mechanism such as:
- OAuth 2.0 and OpenID Connect which provide federated identity from the provider of your choice. Google is an OpenID Connect identity provider. There are also several other providers available.
- Firebase Authentication, which provides authentication using username/password and federated identity using Google, Facebook, Twitter, and more.
- Google Identity Platform, which provides many options for authentication and authorization of Google user accounts.
- Auth0, which provides authentication with various identity providers and single sign-on features.
In general we recommend that you use a testing approach that is idiomatic to Python rather than being dependent on
dev_appserver. For example, you might use
virtualenv to create an isolated local Python 3.7 environment. Any standard Python testing framework can be used to write your unit, integration, and system tests. You might also consider setting up development versions of your services or use the local emulators that are available for many Google Cloud products.
As an optional feature for those who do choose to use it, we are offering an alpha version of an updated
dev_appserver which supports Python 3. Please see Using the Local Development Server for more information
on this option.