Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 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 |
Georg Brandl | 57e3b68 | 2007-08-31 08:07:45 +0000 | [diff] [blame^] | 25 | same language may work differently. On the other hand, CPython is the one |
| 26 | Python implementation in widespread use (although alternate implementations |
| 27 | continue to gain support), and its particular quirks are sometimes worth being |
| 28 | mentioned, especially where the implementation imposes additional limitations. |
| 29 | Therefore, you'll find short "implementation notes" sprinkled throughout the |
| 30 | text. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 31 | |
| 32 | Every Python implementation comes with a number of built-in and standard |
| 33 | modules. These are documented in :ref:`library-index`. A few built-in modules |
| 34 | are mentioned when they interact in a significant way with the language |
| 35 | definition. |
| 36 | |
| 37 | |
| 38 | .. _implementations: |
| 39 | |
| 40 | Alternate Implementations |
| 41 | ========================= |
| 42 | |
| 43 | Though there is one Python implementation which is by far the most popular, |
| 44 | there are some alternate implementations which are of particular interest to |
| 45 | different audiences. |
| 46 | |
| 47 | Known implementations include: |
| 48 | |
| 49 | CPython |
| 50 | This is the original and most-maintained implementation of Python, written in C. |
| 51 | New language features generally appear here first. |
| 52 | |
| 53 | Jython |
| 54 | Python implemented in Java. This implementation can be used as a scripting |
| 55 | language for Java applications, or can be used to create applications using the |
| 56 | Java class libraries. It is also often used to create tests for Java libraries. |
| 57 | More information can be found at `the Jython website <http://www.jython.org/>`_. |
| 58 | |
| 59 | Python for .NET |
| 60 | This implementation actually uses the CPython implementation, but is a managed |
| 61 | .NET application and makes .NET libraries available. This was created by Brian |
| 62 | Lloyd. For more information, see the `Python for .NET home page |
| 63 | <http://www.zope.org/Members/Brian/PythonNet>`_. |
| 64 | |
| 65 | IronPython |
| 66 | An alternate Python for .NET. Unlike Python.NET, this is a complete Python |
| 67 | implementation that generates IL, and compiles Python code directly to .NET |
| 68 | assemblies. It was created by Jim Hugunin, the original creator of Jython. For |
| 69 | more information, see `the IronPython website |
| 70 | <http://workspaces.gotdotnet.com/ironpython>`_. |
| 71 | |
| 72 | PyPy |
| 73 | An implementation of Python written in Python; even the bytecode interpreter is |
| 74 | written in Python. This is executed using CPython as the underlying |
| 75 | interpreter. One of the goals of the project is to encourage experimentation |
| 76 | with the language itself by making it easier to modify the interpreter (since it |
| 77 | is written in Python). Additional information is available on `the PyPy |
| 78 | project's home page <http://codespeak.net/pypy/>`_. |
| 79 | |
| 80 | Each of these implementations varies in some way from the language as documented |
| 81 | in this manual, or introduces specific information beyond what's covered in the |
| 82 | standard Python documentation. Please refer to the implementation-specific |
| 83 | documentation to determine what else you need to know about the specific |
| 84 | implementation you're using. |
| 85 | |
| 86 | |
| 87 | .. _notation: |
| 88 | |
| 89 | Notation |
| 90 | ======== |
| 91 | |
Georg Brandl | 57e3b68 | 2007-08-31 08:07:45 +0000 | [diff] [blame^] | 92 | .. index:: BNF, grammar, syntax, notation |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 93 | |
| 94 | The descriptions of lexical analysis and syntax use a modified BNF grammar |
| 95 | notation. This uses the following style of definition: |
| 96 | |
| 97 | .. productionlist:: * |
| 98 | name: `lc_letter` (`lc_letter` | "_")* |
| 99 | lc_letter: "a"..."z" |
| 100 | |
| 101 | The first line says that a ``name`` is an ``lc_letter`` followed by a sequence |
| 102 | of zero or more ``lc_letter``\ s and underscores. An ``lc_letter`` in turn is |
| 103 | any of the single characters ``'a'`` through ``'z'``. (This rule is actually |
| 104 | adhered to for the names defined in lexical and grammar rules in this document.) |
| 105 | |
| 106 | Each rule begins with a name (which is the name defined by the rule) and |
| 107 | ``::=``. A vertical bar (``|``) is used to separate alternatives; it is the |
| 108 | least binding operator in this notation. A star (``*``) means zero or more |
| 109 | repetitions of the preceding item; likewise, a plus (``+``) means one or more |
| 110 | repetitions, and a phrase enclosed in square brackets (``[ ]``) means zero or |
| 111 | one occurrences (in other words, the enclosed phrase is optional). The ``*`` |
| 112 | and ``+`` operators bind as tightly as possible; parentheses are used for |
| 113 | grouping. Literal strings are enclosed in quotes. White space is only |
| 114 | meaningful to separate tokens. Rules are normally contained on a single line; |
| 115 | rules with many alternatives may be formatted alternatively with each line after |
| 116 | the first beginning with a vertical bar. |
| 117 | |
Georg Brandl | 57e3b68 | 2007-08-31 08:07:45 +0000 | [diff] [blame^] | 118 | .. index:: lexical definitions, ASCII |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 119 | |
| 120 | In lexical definitions (as the example above), two more conventions are used: |
| 121 | Two literal characters separated by three dots mean a choice of any single |
| 122 | character in the given (inclusive) range of ASCII characters. A phrase between |
| 123 | angular brackets (``<...>``) gives an informal description of the symbol |
| 124 | defined; e.g., this could be used to describe the notion of 'control character' |
| 125 | if needed. |
| 126 | |
| 127 | Even though the notation used is almost the same, there is a big difference |
| 128 | between the meaning of lexical and syntactic definitions: a lexical definition |
| 129 | operates on the individual characters of the input source, while a syntax |
| 130 | definition operates on the stream of tokens generated by the lexical analysis. |
| 131 | All uses of BNF in the next chapter ("Lexical Analysis") are lexical |
| 132 | definitions; uses in subsequent chapters are syntactic definitions. |
| 133 | |