Doc/ref/ref1.tex

   1 \chapter{Introduction\label{introduction}}
   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.
  16 If you would like to see a more formal definition of the language,
  17 maybe you could volunteer your time --- or invent a cloning machine
  18 :-).
  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
  23 other hand, there is currently only one Python implementation in
  24 widespread use (although alternate implementations exist), and
  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
  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.
  35
  36
  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
  87 \section{Notation\label{notation}}
  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
  96 \begin{productionlist}
  97   \production{name}{\token{lc_letter} (\token{lc_letter} | "_")*}
  98   \production{lc_letter}{"a"..."z"}
  99 \end{productionlist}
 100
 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.)
 106
 107 Each rule begins with a name (which is the name defined by the rule)
 108 and \code{::=}.  A vertical bar (\code{|}) is used to separate
 109 alternatives; it is the least binding operator in this notation.  A
 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
 113 occurrences (in other words, the enclosed phrase is optional).  The
 114 \code{*} and \code{+} operators bind as tightly as possible;
 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{}
 124 characters.  A phrase between angular brackets (\code{<...>}) gives an
 125 informal description of the symbol defined; e.g., this could be used
 126 to describe the notion of `control character' if needed.
 127 \index{lexical definitions}
 128 \index{ASCII@\ASCII}
 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.