[2] | 1 |
|
---|
| 2 | .. _introduction:
|
---|
| 3 |
|
---|
| 4 | ************
|
---|
| 5 | Introduction
|
---|
| 6 | ************
|
---|
| 7 |
|
---|
| 8 | This reference manual describes the Python programming language. It is not
|
---|
| 9 | intended as a tutorial.
|
---|
| 10 |
|
---|
| 11 | While I am trying to be as precise as possible, I chose to use English rather
|
---|
| 12 | than formal specifications for everything except syntax and lexical analysis.
|
---|
| 13 | This should make the document more understandable to the average reader, but
|
---|
| 14 | will leave room for ambiguities. Consequently, if you were coming from Mars and
|
---|
| 15 | tried to re-implement Python from this document alone, you might have to guess
|
---|
| 16 | things and in fact you would probably end up implementing quite a different
|
---|
| 17 | language. On the other hand, if you are using Python and wonder what the precise
|
---|
| 18 | rules about a particular area of the language are, you should definitely be able
|
---|
| 19 | to find them here. If you would like to see a more formal definition of the
|
---|
| 20 | language, maybe you could volunteer your time --- or invent a cloning machine
|
---|
| 21 | :-).
|
---|
| 22 |
|
---|
| 23 | It is dangerous to add too many implementation details to a language reference
|
---|
| 24 | document --- the implementation may change, and other implementations of the
|
---|
| 25 | same language may work differently. On the other hand, there is currently only
|
---|
| 26 | one Python implementation in widespread use (although alternate implementations
|
---|
| 27 | exist), and its particular quirks are sometimes worth being mentioned,
|
---|
| 28 | especially where the implementation imposes additional limitations. Therefore,
|
---|
| 29 | you'll find short "implementation notes" sprinkled throughout the text.
|
---|
| 30 |
|
---|
| 31 | Every Python implementation comes with a number of built-in and standard
|
---|
| 32 | modules. These are documented in :ref:`library-index`. A few built-in modules
|
---|
| 33 | are mentioned when they interact in a significant way with the language
|
---|
| 34 | definition.
|
---|
| 35 |
|
---|
| 36 |
|
---|
| 37 | .. _implementations:
|
---|
| 38 |
|
---|
| 39 | Alternate Implementations
|
---|
| 40 | =========================
|
---|
| 41 |
|
---|
| 42 | Though there is one Python implementation which is by far the most popular,
|
---|
| 43 | there are some alternate implementations which are of particular interest to
|
---|
| 44 | different audiences.
|
---|
| 45 |
|
---|
| 46 | Known implementations include:
|
---|
| 47 |
|
---|
| 48 | CPython
|
---|
| 49 | This is the original and most-maintained implementation of Python, written in C.
|
---|
| 50 | New language features generally appear here first.
|
---|
| 51 |
|
---|
| 52 | Jython
|
---|
| 53 | Python implemented in Java. This implementation can be used as a scripting
|
---|
| 54 | language for Java applications, or can be used to create applications using the
|
---|
| 55 | Java class libraries. It is also often used to create tests for Java libraries.
|
---|
| 56 | More information can be found at `the Jython website <http://www.jython.org/>`_.
|
---|
| 57 |
|
---|
| 58 | Python for .NET
|
---|
| 59 | This implementation actually uses the CPython implementation, but is a managed
|
---|
| 60 | .NET application and makes .NET libraries available. It was created by Brian
|
---|
| 61 | Lloyd. For more information, see the `Python for .NET home page
|
---|
| 62 | <http://pythonnet.sourceforge.net>`_.
|
---|
| 63 |
|
---|
| 64 | IronPython
|
---|
| 65 | An alternate Python for .NET. Unlike Python.NET, this is a complete Python
|
---|
| 66 | implementation that generates IL, and compiles Python code directly to .NET
|
---|
| 67 | assemblies. It was created by Jim Hugunin, the original creator of Jython. For
|
---|
[391] | 68 | more information, see `the IronPython website <http://www.ironpython.net/>`_.
|
---|
[2] | 69 |
|
---|
| 70 | PyPy
|
---|
[391] | 71 | An implementation of Python written completely in Python. It supports several
|
---|
| 72 | advanced features not found in other implementations like stackless support
|
---|
| 73 | and a Just in Time compiler. One of the goals of the project is to encourage
|
---|
| 74 | experimentation with the language itself by making it easier to modify the
|
---|
| 75 | interpreter (since it is written in Python). Additional information is
|
---|
| 76 | available on `the PyPy project's home page <http://pypy.org/>`_.
|
---|
[2] | 77 |
|
---|
| 78 | Each of these implementations varies in some way from the language as documented
|
---|
| 79 | in this manual, or introduces specific information beyond what's covered in the
|
---|
| 80 | standard Python documentation. Please refer to the implementation-specific
|
---|
| 81 | documentation to determine what else you need to know about the specific
|
---|
| 82 | implementation you're using.
|
---|
| 83 |
|
---|
| 84 |
|
---|
| 85 | .. _notation:
|
---|
| 86 |
|
---|
| 87 | Notation
|
---|
| 88 | ========
|
---|
| 89 |
|
---|
| 90 | .. index::
|
---|
| 91 | single: BNF
|
---|
| 92 | single: grammar
|
---|
| 93 | single: syntax
|
---|
| 94 | single: notation
|
---|
| 95 |
|
---|
| 96 | The descriptions of lexical analysis and syntax use a modified BNF grammar
|
---|
| 97 | notation. This uses the following style of definition:
|
---|
| 98 |
|
---|
| 99 | .. productionlist:: *
|
---|
| 100 | name: `lc_letter` (`lc_letter` | "_")*
|
---|
| 101 | lc_letter: "a"..."z"
|
---|
| 102 |
|
---|
| 103 | The first line says that a ``name`` is an ``lc_letter`` followed by a sequence
|
---|
| 104 | of zero or more ``lc_letter``\ s and underscores. An ``lc_letter`` in turn is
|
---|
| 105 | any of the single characters ``'a'`` through ``'z'``. (This rule is actually
|
---|
| 106 | adhered to for the names defined in lexical and grammar rules in this document.)
|
---|
| 107 |
|
---|
| 108 | Each rule begins with a name (which is the name defined by the rule) and
|
---|
| 109 | ``::=``. A vertical bar (``|``) is used to separate alternatives; it is the
|
---|
| 110 | least binding operator in this notation. A star (``*``) means zero or more
|
---|
| 111 | repetitions of the preceding item; likewise, a plus (``+``) means one or more
|
---|
| 112 | repetitions, and a phrase enclosed in square brackets (``[ ]``) means zero or
|
---|
| 113 | one occurrences (in other words, the enclosed phrase is optional). The ``*``
|
---|
| 114 | and ``+`` operators bind as tightly as possible; parentheses are used for
|
---|
| 115 | grouping. Literal strings are enclosed in quotes. White space is only
|
---|
| 116 | meaningful to separate tokens. Rules are normally contained on a single line;
|
---|
| 117 | rules with many alternatives may be formatted alternatively with each line after
|
---|
| 118 | the first beginning with a vertical bar.
|
---|
| 119 |
|
---|
| 120 | .. index::
|
---|
| 121 | single: lexical definitions
|
---|
| 122 | single: ASCII@ASCII
|
---|
| 123 |
|
---|
| 124 | In lexical definitions (as the example above), two more conventions are used:
|
---|
| 125 | Two literal characters separated by three dots mean a choice of any single
|
---|
| 126 | character in the given (inclusive) range of ASCII characters. A phrase between
|
---|
| 127 | angular brackets (``<...>``) gives an informal description of the symbol
|
---|
| 128 | defined; e.g., this could be used to describe the notion of 'control character'
|
---|
| 129 | if needed.
|
---|
| 130 |
|
---|
| 131 | Even though the notation used is almost the same, there is a big difference
|
---|
| 132 | between the meaning of lexical and syntactic definitions: a lexical definition
|
---|
| 133 | operates on the individual characters of the input source, while a syntax
|
---|
| 134 | definition operates on the stream of tokens generated by the lexical analysis.
|
---|
| 135 | All uses of BNF in the next chapter ("Lexical Analysis") are lexical
|
---|
| 136 | definitions; uses in subsequent chapters are syntactic definitions.
|
---|
| 137 |
|
---|