Fred Drake | 61c7728 | 1998-07-28 19:34:22 +0000 | [diff] [blame] | 1 | \chapter{Introduction\label{introduction}} |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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. |
Thomas Wouters | f9b526d | 2000-07-16 19:05:38 +0000 | [diff] [blame] | 16 | If you would like to see a more formal definition of the language, |
Guido van Rossum | 0bd3795 | 1998-06-15 16:27:37 +0000 | [diff] [blame] | 17 | maybe you could volunteer your time --- or invent a cloning machine |
| 18 | :-). |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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 |
Guido van Rossum | 0bd3795 | 1998-06-15 16:27:37 +0000 | [diff] [blame] | 23 | other hand, there is currently only one Python implementation in |
Fred Drake | 21c8254 | 2005-07-20 04:33:01 +0000 | [diff] [blame^] | 24 | widespread use (although alternate implementations exist), and |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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 |
Fred Drake | e15eb35 | 1999-11-10 16:13:25 +0000 | [diff] [blame] | 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. |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 35 | |
Fred Drake | 2829f1c | 2001-06-23 05:27:20 +0000 | [diff] [blame] | 36 | |
Fred Drake | 21c8254 | 2005-07-20 04:33:01 +0000 | [diff] [blame^] | 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 | |
Fred Drake | 61c7728 | 1998-07-28 19:34:22 +0000 | [diff] [blame] | 87 | \section{Notation\label{notation}} |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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 | |
Andrew M. Kuchling | 6a15c5d | 2005-06-02 13:50:19 +0000 | [diff] [blame] | 96 | \begin{productionlist} |
| 97 | \production{name}{\token{lc_letter} (\token{lc_letter} | "_")*} |
| 98 | \production{lc_letter}{"a"..."z"} |
| 99 | \end{productionlist} |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 100 | |
Fred Drake | 5c07d9b | 1998-05-14 19:37:06 +0000 | [diff] [blame] | 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.) |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 106 | |
| 107 | Each rule begins with a name (which is the name defined by the rule) |
Andrew M. Kuchling | 6a15c5d | 2005-06-02 13:50:19 +0000 | [diff] [blame] | 108 | and \code{::=}. A vertical bar (\code{|}) is used to separate |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 109 | alternatives; it is the least binding operator in this notation. A |
Fred Drake | 5c07d9b | 1998-05-14 19:37:06 +0000 | [diff] [blame] | 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 |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 113 | occurrences (in other words, the enclosed phrase is optional). The |
Fred Drake | 5c07d9b | 1998-05-14 19:37:06 +0000 | [diff] [blame] | 114 | \code{*} and \code{+} operators bind as tightly as possible; |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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{} |
Fred Drake | 5c07d9b | 1998-05-14 19:37:06 +0000 | [diff] [blame] | 124 | characters. A phrase between angular brackets (\code{<...>}) gives an |
Guido van Rossum | 7c0240f | 1998-07-24 15:36:43 +0000 | [diff] [blame] | 125 | informal description of the symbol defined; e.g., this could be used |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 126 | to describe the notion of `control character' if needed. |
| 127 | \index{lexical definitions} |
Fred Drake | c37b65e | 2001-11-28 07:26:15 +0000 | [diff] [blame] | 128 | \index{ASCII@\ASCII} |
Fred Drake | f666917 | 1998-05-06 19:52:49 +0000 | [diff] [blame] | 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. |