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