mirror of
				https://github.com/python/cpython.git
				synced 2025-11-03 19:34:08 +00:00 
			
		
		
		
	svn+ssh://pythondev@svn.python.org/python/trunk ........ r58931 | vinay.sajip | 2007-11-11 15:27:30 +0100 (Sun, 11 Nov 2007) | 1 line Fixed a bug reported (in private email, by Robert Crida) in logging configuration whereby child loggers of a logger named in a configuration file, which are not themselves named in the configuration, are disabled when the configuration is applied. ........ r58932 | georg.brandl | 2007-11-11 16:16:16 +0100 (Sun, 11 Nov 2007) | 2 lines Remove duplication of "this". ........ r58935 | christian.heimes | 2007-11-12 02:15:40 +0100 (Mon, 12 Nov 2007) | 2 lines Added new decorator syntax to property.__doc__ Guido prefers _x over __x. ........ r58936 | christian.heimes | 2007-11-12 02:20:56 +0100 (Mon, 12 Nov 2007) | 2 lines Fix for #1427: Error in standard module calendar the prweek() method is still broken and I can't figure out how it suppose to work. ........ r58938 | andrew.kuchling | 2007-11-12 02:25:21 +0100 (Mon, 12 Nov 2007) | 1 line Re-word sentence ........
		
			
				
	
	
		
			133 lines
		
	
	
	
		
			6.1 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			133 lines
		
	
	
	
		
			6.1 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
 | 
						|
.. _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, CPython is the one
 | 
						|
Python implementation in widespread use (although alternate implementations
 | 
						|
continue to gain support), 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
 | 
						|
   .NET application and makes .NET libraries available.  It was created by Brian
 | 
						|
   Lloyd.  For more information, see the `Python for .NET home page
 | 
						|
   <http://pythonnet.sourceforge.net>`_.
 | 
						|
 | 
						|
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
 | 
						|
   more information, see `the IronPython website
 | 
						|
   <http://workspaces.gotdotnet.com/ironpython>`_.
 | 
						|
 | 
						|
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:: BNF, grammar, syntax, 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:: lexical definitions, 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.
 | 
						|
 |