← Back to branch summary

~ubuntu-branches/ubuntu/maverick/python3.1/maverick

« back to all changes in this revision

Viewing changes to Doc/reference/introduction.rst

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2009-03-23 00:01:27 UTC
  • Revision ID: james.westby@ubuntu.com-20090323000127-5fstfxju4ufrhthq
Tags: upstream-3.1~a1+20090322
Import upstream version 3.1~a1+20090322

Show diffs side-by-side

added added

removed removed

Lines of Context:
Doc/reference/introduction.rst
 
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, 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.
 
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.  It was created by Brian
 
62
   Lloyd.  For more information, see the `Python for .NET home page
 
63
   <http://pythonnet.sourceforge.net>`_.
 
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 <http://www.ironpython.com/>`_.
 
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:: BNF, grammar, syntax, notation
 
92
 
 
93
The descriptions of lexical analysis and syntax use a modified BNF grammar
 
94
notation.  This uses the following style of definition:
 
95
 
 
96
.. productionlist:: *
 
97
   name: `lc_letter` (`lc_letter` | "_")*
 
98
   lc_letter: "a"..."z"
 
99
 
 
100
The first line says that a ``name`` is an ``lc_letter`` followed by a sequence
 
101
of zero or more ``lc_letter``\ s and underscores.  An ``lc_letter`` in turn is
 
102
any of the single characters ``'a'`` through ``'z'``.  (This rule is actually
 
103
adhered to for the names defined in lexical and grammar rules in this document.)
 
104
 
 
105
Each rule begins with a name (which is the name defined by the rule) and
 
106
``::=``.  A vertical bar (``|``) is used to separate alternatives; it is the
 
107
least binding operator in this notation.  A star (``*``) means zero or more
 
108
repetitions of the preceding item; likewise, a plus (``+``) means one or more
 
109
repetitions, and a phrase enclosed in square brackets (``[ ]``) means zero or
 
110
one occurrences (in other words, the enclosed phrase is optional).  The ``*``
 
111
and ``+`` operators bind as tightly as possible; parentheses are used for
 
112
grouping.  Literal strings are enclosed in quotes.  White space is only
 
113
meaningful to separate tokens. Rules are normally contained on a single line;
 
114
rules with many alternatives may be formatted alternatively with each line after
 
115
the first beginning with a vertical bar.
 
116
 
 
117
.. index:: lexical definitions, ASCII
 
118
 
 
119
In lexical definitions (as the example above), two more conventions are used:
 
120
Two literal characters separated by three dots mean a choice of any single
 
121
character in the given (inclusive) range of ASCII characters.  A phrase between
 
122
angular brackets (``<...>``) gives an informal description of the symbol
 
123
defined; e.g., this could be used to describe the notion of 'control character'
 
124
if needed.
 
125
 
 
126
Even though the notation used is almost the same, there is a big difference
 
127
between the meaning of lexical and syntactic definitions: a lexical definition
 
128
operates on the individual characters of the input source, while a syntax
 
129
definition operates on the stream of tokens generated by the lexical analysis.
 
130
All uses of BNF in the next chapter ("Lexical Analysis") are lexical
 
131
definitions; uses in subsequent chapters are syntactic definitions.
 
132