1. вступ

Цей довідковий посібник описує мову програмування Python. Він не призначений як підручник.

Хоча я намагаюся бути максимально точним, я вирішив використовувати англійську, а не формальні специфікації для всього, крім синтаксису та лексичного аналізу. Це повинно зробити документ більш зрозумілим для пересічного читача, але залишить місце для неоднозначностей. Отже, якби ви прилетіли з Марса й спробували повторно впровадити Python лише з цього документу, вам, можливо, доведеться щось здогадуватися, і насправді ви, ймовірно, закінчили б впровадженням зовсім іншої мови. З іншого боку, якщо ви використовуєте Python і вам цікаво, якими є точні правила щодо певної області мови, ви точно зможете знайти їх тут. Якщо ви бажаєте побачити більш формальне визначення мови, можливо, ви можете приділити свій час — або винайти машину для клонування :-).

Небезпечно додавати забагато деталей реалізації до довідкового документа про мову – реалізація може змінитися, а інші реалізації тієї самої мови можуть працювати по-різному. З іншого боку, CPython є єдиною реалізацією Python, яка широко використовується (хоча альтернативні реалізації продовжують отримувати підтримку), і іноді варто згадати його особливості, особливо якщо реалізація накладає додаткові обмеження. Таким чином, ви знайдете короткі «нотатки щодо реалізації», розкидані по всьому тексту.

Кожна реалізація Python має низку вбудованих і стандартних модулів. Вони задокументовані в Стандартна бібліотека Python. Кілька вбудованих модулів згадуються, коли вони суттєво взаємодіють із визначенням мови.

1.1. Альтернативні реалізації

Хоча існує одна реалізація Python, яка на сьогоднішній день є найпопулярнішою, є кілька альтернативних реалізацій, які становлять особливий інтерес для різних аудиторій.

Відомі реалізації включають:

CPython

Це оригінальна і найбільш підтримувана реалізація Python, написана мовою C. Нові функції мови зазвичай з’являються тут першими.

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 для .NET

Ця реалізація фактично використовує реалізацію CPython, але є керованою програмою .NET і робить доступними бібліотеки .NET. Його створив Браян Ллойд. Щоб отримати додаткові відомості, перегляньте домашню сторінку Python для .NET.

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.

Кожна з цих реалізацій певним чином відрізняється від мови, задокументованої в цьому посібнику, або вводить певну інформацію, окрім того, що описано в стандартній документації Python. Зверніться до документації щодо реалізації, щоб визначити, що ще вам потрібно знати про конкретну реалізацію, яку ви використовуєте.

1.2. Позначення

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.

1.2.1. Lexical and Syntactic definitions

There is some difference between lexical and syntactic analysis: the lexical analyzer operates on the individual characters of the input source, while the parser (syntactic analyzer) operates on the stream of tokens generated by the lexical analysis. However, in some cases the exact boundary between the two phases is a CPython implementation detail.

The practical difference between the two is that in lexical definitions, all whitespace is significant. The lexical analyzer discards all whitespace that is not converted to tokens like token.INDENT or NEWLINE. Syntactic definitions then use these tokens, rather than source characters.

This documentation uses the same BNF grammar for both styles of definitions. All uses of BNF in the next chapter (Лексичний аналіз) are lexical definitions; uses in subsequent chapters are syntactic definitions.