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