2.1.1.Logical lines¶

The end of a logical line is represented by the token NEWLINE. Statementscannot cross logical line boundaries except where NEWLINE is allowed by thesyntax (e.g., between statements in compound statements). A logical line isconstructed from one or morephysical lines by following the explicit orimplicitline joining rules.

2.1.2.Physical lines¶

A physical line is a sequence of characters terminated by an end-of-linesequence. In source files and strings, any of the standard platform linetermination sequences can be used - the Unix form using ASCII LF (linefeed),the Windows form using the ASCII sequence CR LF (return followed by linefeed),or the old Macintosh form using the ASCII CR (return) character. All of theseforms can be used equally, regardless of platform. The end of input also servesas an implicit terminator for the final physical line.

When embedding Python, source code strings should be passed to Python APIs usingthe standard C conventions for newline characters (the\n character,representing ASCII LF, is the line terminator).

2.1.3.Comments¶

A comment starts with a hash character (#) that is not part of a stringliteral, and ends at the end of the physical line. A comment signifies the endof the logical line unless the implicit line joining rules are invoked. Commentsare ignored by the syntax; they are not tokens.

2.1.4.Encoding declarations¶

If a comment in the first or second line of the Python script matches theregular expressioncoding[=:]\s*([-\w.]+), this comment is processed as anencoding declaration; the first group of this expression names the encoding ofthe source code file. The encoding declaration must appear on a line of itsown. If it is the second line, the first line must also be a comment-only line.The recommended forms of an encoding expression are

# -*- coding: <encoding-name> -*-

which is recognized also by GNU Emacs, and

# vim:fileencoding=<encoding-name>

which is recognized by Bram Moolenaar’s VIM. In addition, if the first bytes ofthe file are the UTF-8 byte-order mark ('\xef\xbb\xbf'), the declared fileencoding is UTF-8 (this is supported, among others, by Microsoft’snotepad).

If an encoding is declared, the encoding name must be recognized by Python. Theencoding is used for all lexical analysis, in particular to find the end of astring, and to interpret the contents of Unicode literals. String literals areconverted to Unicode for syntactical analysis, then converted back to theiroriginal encoding before interpretation starts.

2.1.5.Explicit line joining¶

Two or more physical lines may be joined into logical lines using backslashcharacters (\), as follows: when a physical line ends in a backslash that isnot part of a string literal or comment, it is joined with the following forminga single logical line, deleting the backslash and the following end-of-linecharacter. For example:

if1900<year<2100and1<=month<=12 \and1<=day<=31and0<=hour<24 \and0<=minute<60and0<=second<60:# Looks like a valid datereturn1

A line ending in a backslash cannot carry a comment. A backslash does notcontinue a comment. A backslash does not continue a token except for stringliterals (i.e., tokens other than string literals cannot be split acrossphysical lines using a backslash). A backslash is illegal elsewhere on a lineoutside a string literal.

2.1.6.Implicit line joining¶

Expressions in parentheses, square brackets or curly braces can be split overmore than one physical line without using backslashes. For example:

month_names=['Januari','Februari','Maart',# These are the'April','Mei','Juni',# Dutch names'Juli','Augustus','September',# for the months'Oktober','November','December']# of the year

Implicitly continued lines can carry comments. The indentation of thecontinuation lines is not important. Blank continuation lines are allowed.There is no NEWLINE token between implicit continuation lines. Implicitlycontinued lines can also occur within triple-quoted strings (see below); in thatcase they cannot carry comments.

2.1.7.Blank lines¶

A logical line that contains only spaces, tabs, formfeeds and possibly acomment, is ignored (i.e., no NEWLINE token is generated). During interactiveinput of statements, handling of a blank line may differ depending on theimplementation of the read-eval-print loop. In the standard implementation, anentirely blank logical line (i.e. one containing not even whitespace or acomment) terminates a multi-line statement.

2.1.8.Indentation¶

Leading whitespace (spaces and tabs) at the beginning of a logical line is usedto compute the indentation level of the line, which in turn is used to determinethe grouping of statements.

First, tabs are replaced (from left to right) by one to eight spaces such thatthe total number of characters up to and including the replacement is a multipleof eight (this is intended to be the same rule as used by Unix). The totalnumber of spaces preceding the first non-blank character then determines theline’s indentation. Indentation cannot be split over multiple physical linesusing backslashes; the whitespace up to the first backslash determines theindentation.

Cross-platform compatibility note: because of the nature of text editors onnon-UNIX platforms, it is unwise to use a mixture of spaces and tabs for theindentation in a single source file. It should also be noted that differentplatforms may explicitly limit the maximum indentation level.

A formfeed character may be present at the start of the line; it will be ignoredfor the indentation calculations above. Formfeed characters occurring elsewherein the leading whitespace have an undefined effect (for instance, they may resetthe space count to zero).

The indentation levels of consecutive lines are used to generate INDENT andDEDENT tokens, using a stack, as follows.

Before the first line of the file is read, a single zero is pushed on the stack;this will never be popped off again. The numbers pushed on the stack willalways be strictly increasing from bottom to top. At the beginning of eachlogical line, the line’s indentation level is compared to the top of the stack.If it is equal, nothing happens. If it is larger, it is pushed on the stack, andone INDENT token is generated. If it is smaller, itmust be one of thenumbers occurring on the stack; all numbers on the stack that are larger arepopped off, and for each number popped off a DEDENT token is generated. At theend of the file, a DEDENT token is generated for each number remaining on thestack that is larger than zero.

Here is an example of a correctly (though confusingly) indented piece of Pythoncode:

defperm(l):# Compute the list of all permutations of liflen(l)<=1:return[l]r=[]foriinrange(len(l)):s=l[:i]+l[i+1:]p=perm(s)forxinp:r.append(l[i:i+1]+x)returnr

The following example shows various indentation errors:

defperm(l):# error: first line indentedforiinrange(len(l)):# error: not indenteds=l[:i]+l[i+1:]p=perm(l[:i]+l[i+1:])# error: unexpected indentforxinp:r.append(l[i:i+1]+x)returnr# error: inconsistent dedent

(Actually, the first three errors are detected by the parser; only the lasterror is found by the lexical analyzer — the indentation ofreturnr doesnot match a level popped off the stack.)

2.1.9.Whitespace between tokens¶

Except at the beginning of a logical line or in string literals, the whitespacecharacters space, tab and formfeed can be used interchangeably to separatetokens. Whitespace is needed between two tokens only if their concatenationcould otherwise be interpreted as a different token (e.g., ab is one token, buta b is two tokens).

2.3.1.Keywords¶

The following identifiers are used as reserved words, orkeywords of thelanguage, and cannot be used as ordinary identifiers. They must be spelledexactly as written here:

and       del       from      not       whileas        elif      global    or        withassert    else      if        pass      yieldbreak     except    import    printclass     exec      in        raisecontinue  finally   is        returndef       for       lambda    try

2.3.2.Reserved classes of identifiers¶

Certain classes of identifiers (besides keywords) have special meanings. Theseclasses are identified by the patterns of leading and trailing underscorecharacters:

_*

Not imported byfrommoduleimport*. The special identifier_ is usedin the interactive interpreter to store the result of the last evaluation; it isstored in the__builtin__ module. When not in interactive mode,_has no special meaning and is not defined. See sectionThe import statement.

Note

The name_ is often used in conjunction with internationalization;refer to the documentation for thegettext module for moreinformation on this convention.

__*__

System-defined names. These names are defined by the interpreter and itsimplementation (including the standard library). Current system names arediscussed in theSpecial method names section and elsewhere. More will likelybe defined in future versions of Python.Any use of__*__ names, inany context, that does not follow explicitly documented use, is subject tobreakage without warning.

__*

Class-private names. Names in this category, when used within the context of aclass definition, are re-written to use a mangled form to help avoid nameclashes between “private” attributes of base and derived classes. See sectionIdentifiers (Names).

2.4.1.String literals¶

String literals are described by the following lexical definitions:

stringliteral ::=  [stringprefix](shortstring |longstring)stringprefix ::=  "r" | "u" | "ur" | "R" | "U" | "UR" | "Ur" | "uR"                     | "b" | "B" | "br" | "Br" | "bR" | "BR"shortstring ::=  "'"shortstringitem* "'" | '"'shortstringitem* '"'longstring ::=  "'''"longstringitem* "'''"                     | '"""'longstringitem* '"""'shortstringitem ::=shortstringchar |escapeseqlongstringitem ::=longstringchar |escapeseqshortstringchar ::=  <any source character except "\" or newline or the quote>longstringchar ::=  <any source character except "\">escapeseq ::=  "\" <any ASCII character>

One syntactic restriction not indicated by these productions is that whitespaceis not allowed between thestringprefix and the rest of the stringliteral. The source character set is defined by the encoding declaration; it isASCII if no encoding declaration is given in the source file; see sectionEncoding declarations.

In plain English: String literals can be enclosed in matching single quotes(') or double quotes ("). They can also be enclosed in matching groupsof three single or double quotes (these are generally referred to astriple-quoted strings). The backslash (\) character is used to escapecharacters that otherwise have a special meaning, such as newline, backslashitself, or the quote character. String literals may optionally be prefixed witha letter'r' or'R'; such strings are calledraw strings and usedifferent rules for interpreting backslash escape sequences. A prefix of'u' or'U' makes the string a Unicode string. Unicode strings use theUnicode character set as defined by the Unicode Consortium and ISO 10646. Someadditional escape sequences, described below, are available in Unicode strings.A prefix of'b' or'B' is ignored in Python 2; it indicates that theliteral should become a bytes literal in Python 3 (e.g. when code isautomatically converted with 2to3). A'u' or'b' prefix may be followedby an'r' prefix.

In triple-quoted strings, unescaped newlines and quotes are allowed (and areretained), except that three unescaped quotes in a row terminate the string. (A“quote” is the character used to open the string, i.e. either' or".)

Unless an'r' or'R' prefix is present, escape sequences in strings areinterpreted according to rules similar to those used by Standard C. Therecognized escape sequences are:

Notes:

1. Individual code units which form parts of a surrogate pair can be encoded usingthis escape sequence.

2. Any Unicode character can be encoded this way, but characters outside the BasicMultilingual Plane (BMP) will be encoded using a surrogate pair if Python iscompiled to use 16-bit code units (the default).

3. As in Standard C, up to three octal digits are accepted.

4. Unlike in Standard C, exactly two hex digits are required.

5. In a string literal, hexadecimal and octal escapes denote the byte with thegiven value; it is not necessary that the byte encodes a character in the sourcecharacter set. In a Unicode literal, these escapes denote a Unicode characterwith the given value.

Unlike Standard C, all unrecognized escape sequences are left in the stringunchanged, i.e.,the backslash is left in the string. (This behavior isuseful when debugging: if an escape sequence is mistyped, the resulting outputis more easily recognized as broken.) It is also important to note that theescape sequences marked as “(Unicode only)” in the table above fall into thecategory of unrecognized escapes for non-Unicode string literals.

When an'r' or'R' prefix is present, a character following a backslashis included in the string without change, andall backslashes are left in thestring. For example, the string literalr"\n" consists of two characters:a backslash and a lowercase'n'. String quotes can be escaped with abackslash, but the backslash remains in the string; for example,r"\"" is avalid string literal consisting of two characters: a backslash and a doublequote;r"\" is not a valid string literal (even a raw string cannot end inan odd number of backslashes). Specifically,a raw string cannot end in asingle backslash (since the backslash would escape the following quotecharacter). Note also that a single backslash followed by a newline isinterpreted as those two characters as part of the string,not as a linecontinuation.

When an'r' or'R' prefix is used in conjunction with a'u' or'U' prefix, then the\uXXXX and\UXXXXXXXX escape sequences areprocessed whileall other backslashes are left in the string. For example,the string literalur"\u0062\n" consists of three Unicode characters: ‘LATINSMALL LETTER B’, ‘REVERSE SOLIDUS’, and ‘LATIN SMALL LETTER N’. Backslashes canbe escaped with a preceding backslash; however, both remain in the string. As aresult,\uXXXX escape sequences are only recognized when there are an oddnumber of backslashes.

2.4.2.String literal concatenation¶

Multiple adjacent string literals (delimited by whitespace), possibly usingdifferent quoting conventions, are allowed, and their meaning is the same astheir concatenation. Thus,"hello"'world' is equivalent to"helloworld". This feature can be used to reduce the number of backslashesneeded, to split long strings conveniently across long lines, or even to addcomments to parts of strings, for example:

re.compile("[A-Za-z_]"# letter or underscore"[A-Za-z0-9_]*"# letter, digit or underscore)

Note that this feature is defined at the syntactical level, but implemented atcompile time. The ‘+’ operator must be used to concatenate string expressionsat run time. Also note that literal concatenation can use different quotingstyles for each component (even mixing raw strings and triple quoted strings).

2.4.3.Numeric literals¶

There are four types of numeric literals: plain integers, long integers,floating point numbers, and imaginary numbers. There are no complex literals(complex numbers can be formed by adding a real number and an imaginary number).

Note that numeric literals do not include a sign; a phrase like-1 isactually an expression composed of the unary operator ‘-‘ and the literal1.

2.4.4.Integer and long integer literals¶

Integer and long integer literals are described by the following lexicaldefinitions:

longinteger ::=integer ("l" | "L")integer ::=decimalinteger |octinteger |hexinteger |binintegerdecimalinteger ::=nonzerodigitdigit* | "0"octinteger ::=  "0" ("o" | "O")octdigit+ | "0"octdigit+hexinteger ::=  "0" ("x" | "X")hexdigit+bininteger ::=  "0" ("b" | "B")bindigit+nonzerodigit ::=  "1"..."9"octdigit ::=  "0"..."7"bindigit ::=  "0" | "1"hexdigit ::=digit | "a"..."f" | "A"..."F"

Although both lower case'l' and upper case'L' are allowed as suffixfor long integers, it is strongly recommended to always use'L', since theletter'l' looks too much like the digit'1'.

Plain integer literals that are above the largest representable plain integer(e.g., 2147483647 when using 32-bit arithmetic) are accepted as if they werelong integers instead.1 There is no limit for long integer literals apartfrom what can be stored in available memory.

Some examples of plain integer literals (first row) and long integer literals(second and third rows):

7214748364701773L79228162514264337593543950336L0377L0x100000000L792281625142643375935439503360xdeadbeef

2.4.5.Floating point literals¶

Floating point literals are described by the following lexical definitions:

floatnumber ::=pointfloat |exponentfloatpointfloat ::=  [intpart]fraction |intpart "."exponentfloat ::=  (intpart |pointfloat)exponentintpart ::=digit+fraction ::=  "."digit+exponent ::=  ("e" | "E") ["+" | "-"]digit+

Note that the integer and exponent parts of floating point numbers can look likeoctal integers, but are interpreted using radix 10. For example,077e010 islegal, and denotes the same number as77e10. The allowed range of floatingpoint literals is implementation-dependent. Some examples of floating pointliterals:

3.1410..0011e1003.14e-100e0

Note that numeric literals do not include a sign; a phrase like-1 isactually an expression composed of the unary operator- and the literal1.

2.4.6.Imaginary literals¶

Imaginary literals are described by the following lexical definitions:

imagnumber ::=  (floatnumber |intpart) ("j" | "J")

An imaginary literal yields a complex number with a real part of 0.0. Complexnumbers are represented as a pair of floating point numbers and have the samerestrictions on their range. To create a complex number with a nonzero realpart, add a floating point number to it, e.g.,(3+4j). Some examples ofimaginary literals:

3.14j10.j10j.001j1e100j3.14e-10j