Skip to page content Skip to main navigation
English | Site Directory

e.g. "templates" or "datastore"

# Python Runtime Environment

App Engine executes your Python application code using a pre-loaded Python interpreter in a safe "sandboxed" environment. Your app receives web requests, performs work, and sends responses by interacting with this environment.

- Selecting the Python Runtime
- Requests and CGI
- Responses
- The Request Timer
- The Sandbox
- Pure Python
- App Caching
- Logging
- The Environment
- Quotas and Limits

## Selecting the Python Runtime

App Engine knows to use the Python runtime environment for your application code when you use the tool named `appcfg.py` from the Python SDK with a configuration file named `app.yaml`. You select the Python runtime environment using the following configuration elements:

    runtime: python
    api_version: 1

The first element, `runtime`, selects the Python runtime environment. As of this writing, App Engine only supports one kind of runtime environment, `python`.

The second element, `api_version`, selects which version of the Python runtime environment to use. As of this writing, App Engine only has one version of the Python environment, `1`. If the App Engine team ever needs to release changes to the environment that may not be compatible with existing code, they will do so with a new version identifier. Your app will continue to use the selected version until you change the `api_version` setting and upload your app.

For more information about `app.yaml` and `appcfg.py`, see Python Application Configuration and Uploading an App.

## Requests and CGI

When App Engine receives a web request for your application, it calls the handler script that corresponds to the URL, as described in the application's app.yaml configuration file. App Engine uses the CGI standard to communicate the request data to the handler, and receive the response.

App Engine uses multiple web servers to run your application, and automatically adjusts the number of servers it is using to handle requests reliably. A given request may be routed to any server, and it may not be the same server that handled a previous request from the same user.

The server determines which Python handler script to run by comparing the URL of the request to the URL patterns in the app's configuration file. It then runs the handler in a CGI environment populated with the request data. As described in the CGI standard, the server puts the request data in environment variables and the standard input stream. The script performs actions appropriate to the request, then prepares a response and puts it on the standard output stream.

Most applications use a library to parse CGI requests and return CGI responses, such as the cgi module from the Python standard library, or a web framework that knows the CGI protocol (such as webapp). You can refer to the CGI documentation for details about the environment variables and the format of the input stream data.

The following example handler script displays a message on the user's browser. It prints an HTTP header that identifies the type of the message and the content of message to the standard output stream.

    print "Content-Type: text/plain"
    print ""
    print "Hello, world!"

## Responses

App Engine collects all of the data the request handler script writes to the standard output stream, then waits for the script to exit. When the script exits, all of the output data is sent to the user.

App Engine does not support sending data to the user's browser before exiting the handler. Some web servers use this technique to "stream" data to the user's browser over a period of time in response to a single request. App Engine does not support this streaming technique.

If the client sends HTTP headers with the request indicating that the client can accept compressed (gzip'd) content, App Engine compresses the response data automatically and attaches the appropriate response headers. It uses both the `Accept-Encoding` and `User-Agent` request headers to determine if the client can reliably receive compressed responses. Custom clients can force content to be compressed by specifying both `Accept-Encoding` and `User-Agent` headers with a value of "gzip".

## The Request Timer

A request handler has a limited amount of time to generate and return a response to a request, typically around 30 seconds. Once the deadline has been reached, the request handler is interrupted.

The Python runtime environment interrupts the request handler by raising a `DeadlineExceededError`, from the package `google.appengine.runtime`. If the request handler does not catch this exception, as with all uncaught exceptions, the runtime environment will return an HTTP 500 server error to the client.

The request handler can catch this error to customize the response. The runtime environment gives the request handler a little bit more time (less than a second) after raising the exception to prepare a custom response.

    from google.appengine.runtime import DeadlineExceededError

    class MainPage(webapp.RequestHandler):
      def get(self):
        try:
          # Do stuff...

        except DeadlineExceededError:
          self.response.clear()
          self.response.set_status(500)
          self.response.out.write("This operation could not be completed in time...")

If the handler hasn't returned a response or raised an exception by the second deadline, the handler is terminated and a default error response is returned.

While a request can take as long as 30 seconds to respond, App Engine is optimized for applications with short-lived requests, typically those that take a few hundred milliseconds. An efficient app responds quickly for the majority of requests. An app that doesn't will not scale well with App Engine's infrastructure.

## The Sandbox

To allow App Engine to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted "sandbox" environment. In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's web request and prepare the response.

An App Engine application cannot:

- write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from the filesystem is allowed, and all application files uploaded with the application are available.
- open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
- spawn a sub-process or thread. A web request to an application must be handled in a single process within a few seconds. Processes that take a very long time to respond are terminated to avoid overloading the web server.
- make other kinds of system calls.

## Pure Python

The Python runtime environment uses Python 2.5.2.

All code for the Python runtime environment must be pure Python, and not include any C extensions or other code that must be compiled.

The environment includes the Python standard library. Some modules have been disabled because their core functions are not supported by App Engine, such as networking or writing to the filesystem. In addition, the `os` module is available, but with unsupported features disabled. An attempt to import an unsupported module or use an unsupported feature will raise an exception.

A few modules from the standard library have been replaced or customized to work with App Engine. For example:

- cPickle is aliased to pickle. Features specific to cPickle are not supported.
- marshal is empty. An import will succeed, but using it will not.
- These modules are similarly empty: imp, ftplib, select, socket
- tempfile is disabled, except for `TemporaryFile` which is aliased to StringIO.
- logging is available and its use is highly encouraged! See below.

In addition to the Python standard library and the App Engine libraries, the runtime environment includes the following third-party libraries:

- Django 0.96.1
- WebOb 0.9
- PyYAML 3.05

You can include other pure Python libraries with your application by putting the code in your application directory. If you make a symbolic link to a module's directory in your application directory, appcfg.py will follow the link and include the module in your app.

The Python module include path includes your application's root directory (the directory containing the `app.yaml` file). Modules you create in your application's root directory are available using a path from the root. Don't forget to create `__init__.py` files in sub-directories, so Python will recognize the sub-directories as packages.

## App Caching

The Python runtime environment caches imported modules between requests on a single web server, similar to how a standalone Python application loads a module only once even if the module is imported by multiple files. If a handler script provides a `main()` routine, the runtime environment also caches the script. Otherwise, the handler script is loaded for every request.

App caching provides a significant benefit in response time. We recommend that all applications use a `main()` routine, as described below.

### Imports Are Cached

For efficiency, the web server keeps imported modules in memory and does not re-load or re-evaluate them on subsequent requests to the same application on the same server. Most modules do not initialize any global data or have other side effects when they are imported, so caching them does not change the behavior of the application.

If your application imports a module that depends on the module being evaluated for every request, the application must accommodate this caching behavior.

The following example demonstrates how an imported module is cached. Because `mymodule` is only imported once for a single web server, the global `mymodule.counter` is only initialized to `0` on the first request served by the server. Subsequent requests use the value from the previous request.

    ### mymodule.py
    counter = 0
    def increment():
      global counter
      counter += 1
      return counter

    ### myhandler.py
    import mymodule

    print "Content-Type: text/plain"
    print ""
    print "My number: " + str(mymodule.increment())

This outputs `My number: #` where `#` is the number of times this handler has been called by the web server that handled the request.

### Handler Scripts Can Also Be Cached

You can tell App Engine to cache the handler script itself, in addition to imported modules. If the handler script defines a function named `main()`, then the script and its global environment will be cached like an imported module. The first request for the script on a given web server evaluates the script normally. For subsequent requests, App Engine calls the `main()` function in the cached environment.

To cache a handler script, App Engine must be able to call `main()` with no arguments. If the handler script does not define a `main()` function, or the `main()` function requires arguments (that don't have defaults), then App Engine loads and evaluates the entire script for every request.

Keeping the parsed Python code in memory saves time and allows for faster responses. Caching the global environment has other potential uses as well:

- Compiled regular expressions. All regular expressions are parsed and stored in a compiled form. You can store compiled regular expressions in global variables, then use app caching to re-use the compiled objects between requests.
- GqlQuery objects. The GQL query string is parsed when the GqlQuery object is created. Re-using a GqlQuery object with parameter binding and the bind() method is faster than re-constructing the object each time. You can store a GqlQuery object with parameter binding for the values in a global variable, then re-use it by binding new parameter values for each request.
- Configuration and data files. If your application loads and parses configuration data from a file, it can retain the parsed data in memory to avoid having to re-load the file with each request.

The handler script should call `main()` when imported. App Engine expects that importing the script calls `main()`, so App Engine does not call it when loading the request handler for the first time on a server.

The following example does the same thing as the previous example, using caching of the handler script's global environment:

    ### myhandler.py

    # A global variable, cached between requests on this web server.
    counter = 0

    def main():
      global counter
      counter += 1
      print "Content-Type: text/plain"
      print ""
      print "My number: " + str(counter)

    if __name__ == "__main__":
      main()

Note: Be careful to not "leak" user-specific information between requests. Avoid global variables unless caching is desired, and always initialize request-specific data inside the `main()` routine.

App caching with `main()` provides a significant improvement in your application's response time. We recommend it for all applications.

## Logging

The App Engine web server captures everything the handler script writes to the standard output stream for the response to the web request. It also captures everything the handler script writes to the standard error stream, and stores it as log data. Log data for your application can be viewed and analyzed using the Administration Console, or downloaded using appcfg.py request_logs.

The App Engine Python runtime environment includes special support for the logging module from the Python standard library to understand logging concepts such as log levels ("debug", "info", "warning", "error", "critical").

    import logging

    from google.appengine.api import users
    from google.appengine.ext import db

    user = users.get_current_user()
    if user:
      q = db.GqlQuery("SELECT * FROM UserPrefs WHERE user = :1", user)
      results = q.fetch(2)
      if len(results) > 1:
        logging.error("more than one UserPrefs object for user %s", str(user))
      if len(results) == 0:
        logging.debug("creating UserPrefs object for user %s", str(user))
        userprefs = UserPrefs(user=user)
        userprefs.put()
      else:
        userprefs = results[0]
    else:
      logging.debug("creating dummy UserPrefs for anonymous user")

## The Environment

The execution environment includes several environment variables useful to the application. Some of these are special to App Engine, while others are part of the CGI standard. Python code can access these variables using the `os.environ` dictionary.

The following environment variables are specific to App Engine:

- `APPLICATION_ID`: The ID of the currently running application.
- `CURRENT_VERSION_ID`: The major and minor version of the currently running application, as "X.Y". The major version number ("X") is specified in the app's `app.yaml` file. The minor version number ("Y") is set automatically when each version of the app is uploaded to App Engine. On the development web server, the minor version is always "1".
- `AUTH_DOMAIN`: The domain used for authenticating users with the Users API. Apps hosted on appspot.com have an `AUTH_DOMAIN` of `gmail.com`, and accept any Google account. Apps hosted on a custom domain using Google Apps have an `AUTH_DOMAIN` equal to the custom domain.

The following environment variables are part of the CGI standard, with special behavior in App Engine:

- `SERVER_SOFTWARE`: In the development web server, this value is "Development/X.Y" where "X.Y" is the version of the runtime.

Additional environment variables are set according to the CGI standard. For more information on these variables, see the CGI standard.

Tip: The following webapp request handler displays every environment variable visible to the application in the browser:

    from google.appengine.ext import webapp
    import os

    class PrintEnvironmentHandler(webapp.RequestHandler):
      def get(self):
        for name in os.environ.keys():
          self.response.out.write("%s = %s<br />\n" % (name, os.environ[name]))

## Quotas and Limits

Each incoming request to the application counts toward the Requests quota.

Data received as part of a request counts toward the Incoming Bandwidth (billable) quota. Data sent in response to a request counts toward the Outgoing Bandwidth (billable) quota.

Both HTTP and HTTPS (secure) requests count toward the Requests, Incoming Bandwidth (billable) and Outgoing Bandwidth (billable) quotas. The Quota Details page of the Admin Console also reports Secure Requests, Secure Incoming Bandwidth and Secure Outgoing Bandwidth as separate values for informational purposes. Only HTTPS requests count toward these values.

CPU processing time spent executing a request handler counts toward the CPU Time (billable) quota.

For more information on quotas, see Quotas, and the "Quota Details" section of the Admin Console.

In addition to quotas, the following limits apply to request handlers:

Limit | Amount
--- | ---
request size | 10 megabytes
response size | 10 megabytes
request duration | 30 seconds
simultaneous dynamic requests | 30 *
maximum number of application files | 1,000
maximum number of static files | 1,000
maximum size of an application file | 10 megabytes
maximum size of a static file | 10 megabytes
maximum total size of all application and static files | 150 megabytes

* An application can process around 30 active dynamic requests simultaneously. This means that an application whose average server-side request processing time is 75 milliseconds can serve up to (1000 ms/second / 75 ms/request) * 30 = 400 requests/second without incurring any additional latency. Applications that are heavily CPU-bound may incur some additional latency in long-running requests in order to make room for other apps sharing the same servers. Requests for static files are not affected by this limit.