|
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 |
|
68 more information, see `the IronPython website |
|
69 <http://workspaces.gotdotnet.com/ironpython>`_. |
|
70 |
|
71 PyPy |
|
72 An implementation of Python written in Python; even the bytecode interpreter is |
|
73 written in Python. This is executed using CPython as the underlying |
|
74 interpreter. One of the goals of the project is to encourage experimentation |
|
75 with the language itself by making it easier to modify the interpreter (since it |
|
76 is written in Python). Additional information is available on `the PyPy |
|
77 project's home page <http://codespeak.net/pypy/>`_. |
|
78 |
|
79 Each of these implementations varies in some way from the language as documented |
|
80 in this manual, or introduces specific information beyond what's covered in the |
|
81 standard Python documentation. Please refer to the implementation-specific |
|
82 documentation to determine what else you need to know about the specific |
|
83 implementation you're using. |
|
84 |
|
85 |
|
86 .. _notation: |
|
87 |
|
88 Notation |
|
89 ======== |
|
90 |
|
91 .. index:: |
|
92 single: BNF |
|
93 single: grammar |
|
94 single: syntax |
|
95 single: notation |
|
96 |
|
97 The descriptions of lexical analysis and syntax use a modified BNF grammar |
|
98 notation. This uses the following style of definition: |
|
99 |
|
100 .. productionlist:: * |
|
101 name: `lc_letter` (`lc_letter` | "_")* |
|
102 lc_letter: "a"..."z" |
|
103 |
|
104 The first line says that a ``name`` is an ``lc_letter`` followed by a sequence |
|
105 of zero or more ``lc_letter``\ s and underscores. An ``lc_letter`` in turn is |
|
106 any of the single characters ``'a'`` through ``'z'``. (This rule is actually |
|
107 adhered to for the names defined in lexical and grammar rules in this document.) |
|
108 |
|
109 Each rule begins with a name (which is the name defined by the rule) and |
|
110 ``::=``. A vertical bar (``|``) is used to separate alternatives; it is the |
|
111 least binding operator in this notation. A star (``*``) means zero or more |
|
112 repetitions of the preceding item; likewise, a plus (``+``) means one or more |
|
113 repetitions, and a phrase enclosed in square brackets (``[ ]``) means zero or |
|
114 one occurrences (in other words, the enclosed phrase is optional). The ``*`` |
|
115 and ``+`` operators bind as tightly as possible; parentheses are used for |
|
116 grouping. Literal strings are enclosed in quotes. White space is only |
|
117 meaningful to separate tokens. Rules are normally contained on a single line; |
|
118 rules with many alternatives may be formatted alternatively with each line after |
|
119 the first beginning with a vertical bar. |
|
120 |
|
121 .. index:: |
|
122 single: lexical definitions |
|
123 single: ASCII@ASCII |
|
124 |
|
125 In lexical definitions (as the example above), two more conventions are used: |
|
126 Two literal characters separated by three dots mean a choice of any single |
|
127 character in the given (inclusive) range of ASCII characters. A phrase between |
|
128 angular brackets (``<...>``) gives an informal description of the symbol |
|
129 defined; e.g., this could be used to describe the notion of 'control character' |
|
130 if needed. |
|
131 |
|
132 Even though the notation used is almost the same, there is a big difference |
|
133 between the meaning of lexical and syntactic definitions: a lexical definition |
|
134 operates on the individual characters of the input source, while a syntax |
|
135 definition operates on the stream of tokens generated by the lexical analysis. |
|
136 All uses of BNF in the next chapter ("Lexical Analysis") are lexical |
|
137 definitions; uses in subsequent chapters are syntactic definitions. |
|
138 |