1.1. Alternate Implementations¶

Though there is one Python implementation which is by far the most popular, there are some alternate implementations which are of particular interest to different audiences.

Known implementations include:

CPython

This is the original and most-maintained implementation of Python, written in C. New language features generally appear here first.

Jython

Python implemented in Java. This implementation can be used as a scripting language for Java applications, or can be used to create applications using the Java class libraries. It is also often used to create tests for Java libraries. More information can be found at the Jython website.

Python for .NET

This implementation actually uses the CPython implementation, but is a managed .NET application and makes .NET libraries available. It was created by Brian Lloyd. For more information, see the Python for .NET home page.

IronPython

An alternate Python for .NET. Unlike Python.NET, this is a complete Python implementation that generates IL, and compiles Python code directly to .NET assemblies. It was created by Jim Hugunin, the original creator of Jython. For more information, see the IronPython website.

PyPy

An implementation of Python written completely in Python. It supports several advanced features not found in other implementations like stackless support and a Just in Time compiler. One of the goals of the project is to encourage experimentation with the language itself by making it easier to modify the interpreter (since it is written in Python). Additional information is available on the PyPy project’s home page.

Each of these implementations varies in some way from the language as documented in this manual, or introduces specific information beyond what’s covered in the standard Python documentation. Please refer to the implementation-specific documentation to determine what else you need to know about the specific implementation you’re using.

1.2. Notation¶

The descriptions of lexical analysis and syntax use a grammar notation that is a mixture of EBNF and PEG. For example:

name:   letter (letter | digit | "_")*
letter: "a"..."z" | "A"..."Z"
digit:  "0"..."9"

In this example, the first line says that a name is a letter followed by a sequence of zero or more letters, digits, and underscores. A letter in turn is any of the single characters 'a' through 'z' and A through Z; a digit is a single character from 0 to 9.

Each rule begins with a name (which identifies the rule that’s being defined) followed by a colon, :. The definition to the right of the colon uses the following syntax elements:

• name: A name refers to another rule. Where possible, it is a link to the rule’s definition.

  • TOKEN: An uppercase name refers to a token. For the purposes of grammar definitions, tokens are the same as rules.

• "text", 'text': Text in single or double quotes must match literally (without the quotes). The type of quote is chosen according to the meaning of text:

  • 'if': A name in single quotes denotes a keyword.

  • "case": A name in double quotes denotes a soft-keyword.

  • '@': A non-letter symbol in single quotes denotes an OP token, that is, a delimiter or operator.

• e1 e2: Items separated only by whitespace denote a sequence. Here, e1 must be followed by e2.

• e1 | e2: A vertical bar is used to separate alternatives. It denotes PEG’s “ordered choice”: if e1 matches, e2 is not considered. In traditional PEG grammars, this is written as a slash, /, rather than a vertical bar. See PEP 617 for more background and details.

• e*: A star means zero or more repetitions of the preceding item.

• e+: Likewise, a plus means one or more repetitions.

• [e]: A phrase enclosed in square brackets means zero or one occurrences. In other words, the enclosed phrase is optional.

• e?: A question mark has exactly the same meaning as square brackets: the preceding item is optional.

• (e): Parentheses are used for grouping.

The following notation is only used in lexical definitions.

• "a"..."z": Two literal characters separated by three dots mean a choice of any single character in the given (inclusive) range of ASCII characters.

• <...>: A phrase between angular brackets gives an informal description of the matched symbol (for example, <any ASCII character except "\">), or an abbreviation that is defined in nearby text (for example, <Lu>).

Some definitions also use lookaheads, which indicate that an element must (or must not) match at a given position, but without consuming any input:

• &e: a positive lookahead (that is, e is required to match)

• !e: a negative lookahead (that is, e is required not to match)

The unary operators (*, +, ?) bind as tightly as possible; the vertical bar (|) binds most loosely.

White space is only meaningful to separate tokens.

Rules are normally contained on a single line, but rules that are too long may be wrapped:

literal: stringliteral | bytesliteral
         | integer | floatnumber | imagnumber

Alternatively, rules may be formatted with the first line ending at the colon, and each alternative beginning with a vertical bar on a new line. For example:

literal:
   | stringliteral
   | bytesliteral
   | integer
   | floatnumber
   | imagnumber

This does not mean that there is an empty first alternative.