2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
.. _introduction:
|
|
|
|
|
|
|
|
************
|
|
|
|
Introduction
|
|
|
|
************
|
|
|
|
|
|
|
|
This reference manual describes the Python programming language. It is not
|
|
|
|
intended as a tutorial.
|
|
|
|
|
|
|
|
While I am trying to be as precise as possible, I chose to use English rather
|
|
|
|
than formal specifications for everything except syntax and lexical analysis.
|
|
|
|
This should make the document more understandable to the average reader, but
|
|
|
|
will leave room for ambiguities. Consequently, if you were coming from Mars and
|
|
|
|
tried to re-implement Python from this document alone, you might have to guess
|
|
|
|
things and in fact you would probably end up implementing quite a different
|
|
|
|
language. On the other hand, if you are using Python and wonder what the precise
|
|
|
|
rules about a particular area of the language are, you should definitely be able
|
|
|
|
to find them here. If you would like to see a more formal definition of the
|
|
|
|
language, maybe you could volunteer your time --- or invent a cloning machine
|
|
|
|
:-).
|
|
|
|
|
|
|
|
It is dangerous to add too many implementation details to a language reference
|
|
|
|
document --- the implementation may change, and other implementations of the
|
|
|
|
same language may work differently. On the other hand, there is currently only
|
|
|
|
one Python implementation in widespread use (although alternate implementations
|
|
|
|
exist), and its particular quirks are sometimes worth being mentioned,
|
|
|
|
especially where the implementation imposes additional limitations. Therefore,
|
|
|
|
you'll find short "implementation notes" sprinkled throughout the text.
|
|
|
|
|
|
|
|
Every Python implementation comes with a number of built-in and standard
|
|
|
|
modules. These are documented in :ref:`library-index`. A few built-in modules
|
|
|
|
are mentioned when they interact in a significant way with the language
|
|
|
|
definition.
|
|
|
|
|
|
|
|
|
|
|
|
.. _implementations:
|
|
|
|
|
|
|
|
Alternate Implementations
|
|
|
|
=========================
|
|
|
|
|
|
|
|
Though there is one Python implementation which is by far the most popular,
|
|
|
|
there are some alternate implementations which are of particular interest to
|
|
|
|
different audiences.
|
|
|
|
|
|
|
|
Known implementations include:
|
|
|
|
|
|
|
|
CPython
|
|
|
|
This is the original and most-maintained implementation of Python, written in C.
|
|
|
|
New language features generally appear here first.
|
|
|
|
|
|
|
|
Jython
|
|
|
|
Python implemented in Java. This implementation can be used as a scripting
|
|
|
|
language for Java applications, or can be used to create applications using the
|
|
|
|
Java class libraries. It is also often used to create tests for Java libraries.
|
|
|
|
More information can be found at `the Jython website <http://www.jython.org/>`_.
|
|
|
|
|
|
|
|
Python for .NET
|
|
|
|
This implementation actually uses the CPython implementation, but is a managed
|
2007-11-11 11:16:16 -04:00
|
|
|
.NET application and makes .NET libraries available. It was created by Brian
|
2007-08-15 11:28:01 -03:00
|
|
|
Lloyd. For more information, see the `Python for .NET home page
|
2008-03-14 21:20:19 -03:00
|
|
|
<http://pythonnet.sourceforge.net>`_.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
IronPython
|
|
|
|
An alternate Python for .NET. Unlike Python.NET, this is a complete Python
|
|
|
|
implementation that generates IL, and compiles Python code directly to .NET
|
|
|
|
assemblies. It was created by Jim Hugunin, the original creator of Jython. For
|
Merged revisions 68582,68718,68720-68721,68724-68727,68859,68973,69288-69289,69293,69295,69297-69301,69409,69414,69570,69573,69576,69728-69730,69769,69776,69803-69805,69840,69896 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r68582 | georg.brandl | 2009-01-13 23:14:01 +0100 (Di, 13 Jan 2009) | 2 lines
Use assertRaises.
........
r68718 | georg.brandl | 2009-01-18 11:42:35 +0100 (So, 18 Jan 2009) | 1 line
#4976: union() and intersection() take multiple args, but talk about "the other".
........
r68720 | georg.brandl | 2009-01-18 11:45:22 +0100 (So, 18 Jan 2009) | 1 line
#4974: fix redundant mention of lists and tuples.
........
r68721 | georg.brandl | 2009-01-18 11:48:16 +0100 (So, 18 Jan 2009) | 1 line
#4914: trunc is in math.
........
r68724 | georg.brandl | 2009-01-18 14:24:10 +0100 (So, 18 Jan 2009) | 1 line
#4979: correct result range for some random functions.
........
r68725 | georg.brandl | 2009-01-18 14:47:26 +0100 (So, 18 Jan 2009) | 1 line
#4857: fix augmented assignment target spec.
........
r68726 | georg.brandl | 2009-01-18 15:41:52 +0100 (So, 18 Jan 2009) | 1 line
#4923: clarify what was added.
........
r68727 | georg.brandl | 2009-01-18 19:25:30 +0100 (So, 18 Jan 2009) | 1 line
#4986: augassigns are not expressions.
........
r68859 | georg.brandl | 2009-01-22 19:29:28 +0100 (Do, 22 Jan 2009) | 2 lines
Clarify wording.
........
r68973 | georg.brandl | 2009-01-26 22:29:38 +0100 (Mo, 26 Jan 2009) | 2 lines
Copy over docs on advanced role features from Sphinx docs.
........
r69288 | georg.brandl | 2009-02-05 11:30:57 +0100 (Do, 05 Feb 2009) | 1 line
#5153: fix typo in example.
........
r69289 | georg.brandl | 2009-02-05 11:37:07 +0100 (Do, 05 Feb 2009) | 1 line
#5144: document that PySys_SetArgv prepends the script directory (or the empty string) to sys.path.
........
r69293 | georg.brandl | 2009-02-05 11:59:28 +0100 (Do, 05 Feb 2009) | 1 line
#5059: fix example.
........
r69295 | georg.brandl | 2009-02-05 12:23:47 +0100 (Do, 05 Feb 2009) | 1 line
PyErr_PrintEx is also in 2.x...
........
r69297 | georg.brandl | 2009-02-05 12:32:18 +0100 (Do, 05 Feb 2009) | 1 line
#5015: document PythonHome API functions.
........
r69298 | georg.brandl | 2009-02-05 12:33:21 +0100 (Do, 05 Feb 2009) | 1 line
#4827: fix callback example.
........
r69299 | georg.brandl | 2009-02-05 12:35:28 +0100 (Do, 05 Feb 2009) | 1 line
#4820: use correct module for ctypes.util.
........
r69300 | georg.brandl | 2009-02-05 12:38:23 +0100 (Do, 05 Feb 2009) | 1 line
#4563: disable alpha and roman lists, fixes wrong formatting of contributor list.
........
r69301 | georg.brandl | 2009-02-05 12:40:35 +0100 (Do, 05 Feb 2009) | 1 line
#5031: fix Thread.daemon property docs.
........
r69409 | georg.brandl | 2009-02-07 13:21:17 +0100 (Sa, 07 Feb 2009) | 1 line
#5174: fix wrong file closing in example.
........
r69414 | georg.brandl | 2009-02-07 19:49:54 +0100 (Sa, 07 Feb 2009) | 1 line
make "super only for new-style classes" a note.
........
r69570 | georg.brandl | 2009-02-13 11:40:14 +0100 (Fr, 13 Feb 2009) | 1 line
#4894: document "newurl" parameter to redirect_request().
........
r69573 | georg.brandl | 2009-02-13 11:44:17 +0100 (Fr, 13 Feb 2009) | 1 line
#3734: document complex coercing behavior better.
........
r69576 | georg.brandl | 2009-02-13 11:56:50 +0100 (Fr, 13 Feb 2009) | 1 line
#1661108: note that urlsafe encoded string can contain "=".
........
r69728 | georg.brandl | 2009-02-18 01:22:55 +0100 (Mi, 18 Feb 2009) | 2 lines
#5297: fix example.
........
r69729 | georg.brandl | 2009-02-18 01:25:13 +0100 (Mi, 18 Feb 2009) | 2 lines
#5296: sequence -> iterable.
........
r69730 | georg.brandl | 2009-02-18 01:31:36 +0100 (Mi, 18 Feb 2009) | 2 lines
#5268: mention VMSError.
........
r69769 | georg.brandl | 2009-02-19 09:30:06 +0100 (Do, 19 Feb 2009) | 1 line
#5310, #3558: fix operator precedence table.
........
r69776 | georg.brandl | 2009-02-19 17:34:51 +0100 (Do, 19 Feb 2009) | 2 lines
#5317: update IronPython URL.
........
r69803 | georg.brandl | 2009-02-20 08:48:21 +0100 (Fr, 20 Feb 2009) | 1 line
#5327: fix a broken link by joining it.
........
r69804 | georg.brandl | 2009-02-20 09:22:21 +0100 (Fr, 20 Feb 2009) | 1 line
At least separate imports from other statements.
........
r69805 | georg.brandl | 2009-02-20 09:45:47 +0100 (Fr, 20 Feb 2009) | 2 lines
Fix punctuation.
........
r69840 | georg.brandl | 2009-02-21 20:09:40 +0100 (Sa, 21 Feb 2009) | 1 line
#5338, #5339: two types in the API manual.
........
r69896 | georg.brandl | 2009-02-23 11:24:23 +0100 (Mo, 23 Feb 2009) | 1 line
#5348: format() converts all kinds of values.
........
2009-02-23 06:41:11 -04:00
|
|
|
more information, see `the IronPython website <http://www.ironpython.com/>`_.
|
2007-08-15 11:28:01 -03:00
|
|
|
|
|
|
|
PyPy
|
|
|
|
An implementation of Python written in Python; even the bytecode interpreter is
|
|
|
|
written in Python. This is executed using CPython as the underlying
|
|
|
|
interpreter. One of the goals of the project is to encourage experimentation
|
|
|
|
with the language itself by making it easier to modify the interpreter (since it
|
|
|
|
is written in Python). Additional information is available on `the PyPy
|
|
|
|
project's home page <http://codespeak.net/pypy/>`_.
|
|
|
|
|
|
|
|
Each of these implementations varies in some way from the language as documented
|
|
|
|
in this manual, or introduces specific information beyond what's covered in the
|
|
|
|
standard Python documentation. Please refer to the implementation-specific
|
|
|
|
documentation to determine what else you need to know about the specific
|
|
|
|
implementation you're using.
|
|
|
|
|
|
|
|
|
|
|
|
.. _notation:
|
|
|
|
|
|
|
|
Notation
|
|
|
|
========
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: BNF
|
|
|
|
single: grammar
|
|
|
|
single: syntax
|
|
|
|
single: notation
|
|
|
|
|
|
|
|
The descriptions of lexical analysis and syntax use a modified BNF grammar
|
|
|
|
notation. This uses the following style of definition:
|
|
|
|
|
|
|
|
.. productionlist:: *
|
|
|
|
name: `lc_letter` (`lc_letter` | "_")*
|
|
|
|
lc_letter: "a"..."z"
|
|
|
|
|
|
|
|
The first line says that a ``name`` is an ``lc_letter`` followed by a sequence
|
|
|
|
of zero or more ``lc_letter``\ s and underscores. An ``lc_letter`` in turn is
|
|
|
|
any of the single characters ``'a'`` through ``'z'``. (This rule is actually
|
|
|
|
adhered to for the names defined in lexical and grammar rules in this document.)
|
|
|
|
|
|
|
|
Each rule begins with a name (which is the name defined by the rule) and
|
|
|
|
``::=``. A vertical bar (``|``) is used to separate alternatives; it is the
|
|
|
|
least binding operator in this notation. A star (``*``) means zero or more
|
|
|
|
repetitions of the preceding item; likewise, a plus (``+``) means one or more
|
|
|
|
repetitions, and a phrase enclosed in square brackets (``[ ]``) means zero or
|
|
|
|
one occurrences (in other words, the enclosed phrase is optional). The ``*``
|
|
|
|
and ``+`` operators bind as tightly as possible; parentheses are used for
|
|
|
|
grouping. Literal strings are enclosed in quotes. White space is only
|
|
|
|
meaningful to separate tokens. Rules are normally contained on a single line;
|
|
|
|
rules with many alternatives may be formatted alternatively with each line after
|
|
|
|
the first beginning with a vertical bar.
|
|
|
|
|
|
|
|
.. index::
|
|
|
|
single: lexical definitions
|
|
|
|
single: ASCII@ASCII
|
|
|
|
|
|
|
|
In lexical definitions (as the example above), two more conventions are used:
|
|
|
|
Two literal characters separated by three dots mean a choice of any single
|
|
|
|
character in the given (inclusive) range of ASCII characters. A phrase between
|
|
|
|
angular brackets (``<...>``) gives an informal description of the symbol
|
|
|
|
defined; e.g., this could be used to describe the notion of 'control character'
|
|
|
|
if needed.
|
|
|
|
|
|
|
|
Even though the notation used is almost the same, there is a big difference
|
|
|
|
between the meaning of lexical and syntactic definitions: a lexical definition
|
|
|
|
operates on the individual characters of the input source, while a syntax
|
|
|
|
definition operates on the stream of tokens generated by the lexical analysis.
|
|
|
|
All uses of BNF in the next chapter ("Lexical Analysis") are lexical
|
|
|
|
definitions; uses in subsequent chapters are syntactic definitions.
|
|
|
|
|