Merged revisions…

Merged revisions 85572-85573,85606,85609-85622,85624,85626-85627,85629,85631,85633,85635-85636,85638-85639,85641-85642 via svnmerge from
svn+ssh://svn.python.org/python/branches/py3k

........
  r85572 | georg.brandl | 2010-10-16 20:51:05 +0200 (Sa, 16 Okt 2010) | 1 line

  #10122: typo fix.
........
  r85573 | georg.brandl | 2010-10-16 20:53:08 +0200 (Sa, 16 Okt 2010) | 1 line

  #10124: typo fix.
........
  r85606 | georg.brandl | 2010-10-17 08:32:59 +0200 (So, 17 Okt 2010) | 1 line

  #10058: tweak wording about exception returns.
........
  r85609 | georg.brandl | 2010-10-17 11:19:03 +0200 (So, 17 Okt 2010) | 1 line

  #8556: use less confusing mapping key in example.
........
  r85610 | georg.brandl | 2010-10-17 11:23:05 +0200 (So, 17 Okt 2010) | 1 line

  #8686: remove potentially confusing wording that does not add any value.
........
  r85611 | georg.brandl | 2010-10-17 11:33:24 +0200 (So, 17 Okt 2010) | 1 line

  #8811: small fixes to sqlite3 docs.
........
  r85612 | georg.brandl | 2010-10-17 11:37:54 +0200 (So, 17 Okt 2010) | 1 line

  #8855: add shelve security warning.
........
  r85613 | georg.brandl | 2010-10-17 11:43:35 +0200 (So, 17 Okt 2010) | 1 line

  Fix hmac docs: it takes and returns bytes, except for hexdigest().
........
  r85614 | georg.brandl | 2010-10-17 11:46:11 +0200 (So, 17 Okt 2010) | 1 line

  #8968: add actual name of token constants.
........
  r85615 | georg.brandl | 2010-10-17 12:05:13 +0200 (So, 17 Okt 2010) | 1 line

  #459007: merge info from PC/getpathp.c and using/windows.rst to document the forming of sys.path under Windows.
........
  r85616 | georg.brandl | 2010-10-17 12:07:29 +0200 (So, 17 Okt 2010) | 1 line

  Fix copy-paste error in example.
........
  r85617 | georg.brandl | 2010-10-17 12:09:06 +0200 (So, 17 Okt 2010) | 1 line

  #5212: md5 weaknesses do not affect hmac, so remove the note about that.
........
  r85618 | georg.brandl | 2010-10-17 12:14:38 +0200 (So, 17 Okt 2010) | 1 line

  #9086: correct wrong terminology about linking with pythonXY.dll.
........
  r85619 | georg.brandl | 2010-10-17 12:15:50 +0200 (So, 17 Okt 2010) | 1 line

  Make file names consistent.
........
  r85620 | georg.brandl | 2010-10-17 12:22:28 +0200 (So, 17 Okt 2010) | 1 line

  Remove second parser module example; it referred to non-readily-available example files, and this kind of discovery is much better done with the AST nowadays anyway.
........
  r85621 | georg.brandl | 2010-10-17 12:24:54 +0200 (So, 17 Okt 2010) | 1 line

  #9105: move pickle warning to a bit more prominent location.
........
  r85622 | georg.brandl | 2010-10-17 12:28:04 +0200 (So, 17 Okt 2010) | 1 line

  #9112: document error() and exit() methods of ArgumentParser.
........
  r85624 | georg.brandl | 2010-10-17 12:34:28 +0200 (So, 17 Okt 2010) | 1 line

  Some markup and style fixes in argparse docs.
........
  r85626 | georg.brandl | 2010-10-17 12:38:20 +0200 (So, 17 Okt 2010) | 1 line

  #9117: fix syntax for class definition.
........
  r85627 | georg.brandl | 2010-10-17 12:44:11 +0200 (So, 17 Okt 2010) | 1 line

  #9138: reword introduction to classes in Python.
........
  r85629 | georg.brandl | 2010-10-17 12:51:45 +0200 (So, 17 Okt 2010) | 1 line

  #5962: clarify sys.exit() vs. threads.
........
  r85631 | georg.brandl | 2010-10-17 12:53:54 +0200 (So, 17 Okt 2010) | 1 line

  Fix capitalization.
........
  r85633 | georg.brandl | 2010-10-17 12:59:41 +0200 (So, 17 Okt 2010) | 1 line

  #9204: remove mentions of removed types in the types module.
........
  r85635 | georg.brandl | 2010-10-17 13:03:22 +0200 (So, 17 Okt 2010) | 1 line

  #5121: fix claims about default values leading to segfaults.
........
  r85636 | georg.brandl | 2010-10-17 13:06:14 +0200 (So, 17 Okt 2010) | 1 line

  #9237: document sys.call_tracing().
........
  r85638 | georg.brandl | 2010-10-17 13:13:37 +0200 (So, 17 Okt 2010) | 1 line

  Port changes to pickle docs apparently lost in py3k.
........
  r85639 | georg.brandl | 2010-10-17 13:23:56 +0200 (So, 17 Okt 2010) | 1 line

  Make twisted example a bit more logical.
........
  r85641 | georg.brandl | 2010-10-17 13:29:07 +0200 (So, 17 Okt 2010) | 1 line

  Fix documentation of dis.opmap direction.
........
  r85642 | georg.brandl | 2010-10-17 13:36:28 +0200 (So, 17 Okt 2010) | 1 line

  #9730: fix example.
........

Doc/c-api/bytearray.rst

@@ -16,7 +16,8 @@ Byte Array Objects
 .. cvar:: PyTypeObject PyByteArray_Type
 
    This instance of :ctype:`PyTypeObject` represents the Python bytearray type;
-   it is the same object as ``bytearray`` in the Python layer.
+   it is the same object as :class:`bytearray` in the Python layer.
+
 
 Type check macros
 ^^^^^^^^^^^^^^^^^

Doc/c-api/bytes.rst

@@ -18,10 +18,8 @@ called with a non-bytes parameter.
 
 .. cvar:: PyTypeObject PyBytes_Type
 
-   .. index:: single: BytesType (in module types)
-
    This instance of :ctype:`PyTypeObject` represents the Python bytes type; it
-   is the same object as ``bytes`` in the Python layer. .
+   is the same object as :class:`bytes` in the Python layer.
 
 
 .. cfunction:: int PyBytes_Check(PyObject *o)

Doc/c-api/complex.rst

@@ -82,7 +82,7 @@ Complex Numbers as Python Objects
 .. cvar:: PyTypeObject PyComplex_Type
 
    This instance of :ctype:`PyTypeObject` represents the Python complex number
-   type. It is the same object as ``complex`` and ``types.ComplexType``.
+   type. It is the same object as :class:`complex` in the Python layer.
 
 
 .. cfunction:: int PyComplex_Check(PyObject *p)

Doc/c-api/dict.rst

@@ -15,13 +15,8 @@ Dictionary Objects
 
 .. cvar:: PyTypeObject PyDict_Type
 
-   .. index::
-      single: DictType (in module types)
-      single: DictionaryType (in module types)
-
    This instance of :ctype:`PyTypeObject` represents the Python dictionary
-   type.  This is exposed to Python programs as ``dict`` and
-   ``types.DictType``.
+   type.  This is the same object as :class:`dict` in the Python layer.
 
 
 .. cfunction:: int PyDict_Check(PyObject *p)

Doc/c-api/float.rst

@@ -15,10 +15,8 @@ Floating Point Objects
 
 .. cvar:: PyTypeObject PyFloat_Type
 
-   .. index:: single: FloatType (in modules types)
-
    This instance of :ctype:`PyTypeObject` represents the Python floating point
-   type.  This is the same object as ``float`` and ``types.FloatType``.
+   type.  This is the same object as :class:`float` in the Python layer.
 
 
 .. cfunction:: int PyFloat_Check(PyObject *p)

Doc/c-api/intro.rst

@@ -361,15 +361,16 @@ traceback.
 
 .. index:: single: PyErr_Occurred()
 
-For C programmers, however, error checking always has to be explicit.   All
-functions in the Python/C API can raise exceptions, unless an  explicit claim is
-made otherwise in a function's documentation.  In  general, when a function
-encounters an error, it sets an exception,  discards any object references that
-it owns, and returns an  error indicator --- usually *NULL* or ``-1``.  A few
-functions  return a Boolean true/false result, with false indicating an error.
-Very few functions return no explicit error indicator or have an  ambiguous
-return value, and require explicit testing for errors with
-:cfunc:`PyErr_Occurred`.
+For C programmers, however, error checking always has to be explicit.  All
+functions in the Python/C API can raise exceptions, unless an explicit claim is
+made otherwise in a function's documentation.  In general, when a function
+encounters an error, it sets an exception, discards any object references that
+it owns, and returns an error indicator.  If not documented otherwise, this
+indicator is either *NULL* or ``-1``, depending on the function's return type.
+A few functions return a Boolean true/false result, with false indicating an
+error.  Very few functions return no explicit error indicator or have an
+ambiguous return value, and require explicit testing for errors with
+:cfunc:`PyErr_Occurred`.  These exceptions are always explicitly documented.
 
 .. index::
    single: PyErr_SetString()

Doc/c-api/list.rst

@@ -15,8 +15,8 @@ List Objects
 
 .. cvar:: PyTypeObject PyList_Type
 
-   This instance of :ctype:`PyTypeObject` represents the Python list type.  This
-   is the same object as ``list`` in the Python layer.
+   This instance of :ctype:`PyTypeObject` represents the Python list type.
+   This is the same object as :class:`list` in the Python layer.
 
 
 .. cfunction:: int PyList_Check(PyObject *p)

Doc/c-api/long.rst

@@ -18,7 +18,7 @@ All integers are implemented as "long" integer objects of arbitrary size.
 .. cvar:: PyTypeObject PyLong_Type
 
    This instance of :ctype:`PyTypeObject` represents the Python integer type.
-   This is the same object as ``int``.
+   This is the same object as :class:`int` in the Python layer.
 
 
 .. cfunction:: int PyLong_Check(PyObject *p)

Doc/c-api/slice.rst

@@ -8,10 +8,8 @@ Slice Objects
 
 .. cvar:: PyTypeObject PySlice_Type
 
-   .. index:: single: SliceType (in module types)
-
-   The type object for slice objects.  This is the same as ``slice`` and
-   ``types.SliceType``.
+   The type object for slice objects.  This is the same as :class:`slice` in the
+   Python layer.
 
 
 .. cfunction:: int PySlice_Check(PyObject *ob)

Doc/c-api/tuple.rst

@@ -15,10 +15,8 @@ Tuple Objects
 
 .. cvar:: PyTypeObject PyTuple_Type
 
-   .. index:: single: TupleType (in module types)
-
-   This instance of :ctype:`PyTypeObject` represents the Python tuple type; it is
-   the same object as ``tuple`` and ``types.TupleType`` in the Python layer..
+   This instance of :ctype:`PyTypeObject` represents the Python tuple type; it
+   is the same object as :class:`tuple` in the Python layer.
 
 
 .. cfunction:: int PyTuple_Check(PyObject *p)

Doc/c-api/type.rst

@@ -15,10 +15,8 @@ Type Objects
 
 .. cvar:: PyObject* PyType_Type
 
-   .. index:: single: TypeType (in module types)
-
-   This is the type object for type objects; it is the same object as ``type`` and
-   ``types.TypeType`` in the Python layer.
+   This is the type object for type objects; it is the same object as
+   :class:`type` in the Python layer.
 
 
 .. cfunction:: int PyType_Check(PyObject *o)

Doc/c-api/unicode.rst

@@ -204,7 +204,7 @@ APIs:
 
 .. cfunction:: PyObject* PyUnicode_FromUnicode(const Py_UNICODE *u, Py_ssize_t size)
 
-   Create a Unicode Object from the Py_UNICODE buffer *u* of the given size. *u*
+   Create a Unicode object from the Py_UNICODE buffer *u* of the given size. *u*
    may be *NULL* which causes the contents to be undefined. It is the user's
    responsibility to fill in the needed data.  The buffer is copied into the new
    object. If the buffer is not *NULL*, the return value might be a shared object.
@@ -214,7 +214,7 @@ APIs:
 
 .. cfunction:: PyObject* PyUnicode_FromStringAndSize(const char *u, Py_ssize_t size)
 
-   Create a Unicode Object from the char buffer *u*.  The bytes will be interpreted
+   Create a Unicode object from the char buffer *u*.  The bytes will be interpreted
    as being UTF-8 encoded.  *u* may also be *NULL* which
    causes the contents to be undefined. It is the user's responsibility to fill in
    the needed data.  The buffer is copied into the new object. If the buffer is not

Doc/c-api/veryhigh.rst

@@ -123,13 +123,13 @@ the same library that the Python runtime is using.
 
 .. cfunction:: int PyRun_InteractiveOneFlags(FILE *fp, const char *filename, PyCompilerFlags *flags)
 
-   Read and execute a single statement from a file associated with an interactive
-   device according to the *flags* argument.  If *filename* is *NULL*, ``"???"`` is
-   used instead.  The user will be prompted using ``sys.ps1`` and ``sys.ps2``.
-   Returns ``0`` when the input was executed successfully, ``-1`` if there was an
-   exception, or an error code from the :file:`errcode.h` include file distributed
-   as part of Python if there was a parse error.  (Note that :file:`errcode.h` is
-   not included by :file:`Python.h`, so must be included specifically if needed.)
+   Read and execute a single statement from a file associated with an
+   interactive device according to the *flags* argument.  The user will be
+   prompted using ``sys.ps1`` and ``sys.ps2``.  Returns ``0`` when the input was
+   executed successfully, ``-1`` if there was an exception, or an error code
+   from the :file:`errcode.h` include file distributed as part of Python if
+   there was a parse error.  (Note that :file:`errcode.h` is not included by
+   :file:`Python.h`, so must be included specifically if needed.)
 
 
 .. cfunction:: int PyRun_InteractiveLoop(FILE *fp, const char *filename)
@@ -138,11 +138,11 @@ the same library that the Python runtime is using.
    leaving *flags* set to *NULL*.
 
 
-.. cfunction:: int PyRun_InteractiveLoopFlags(FILE *fp,  const char *filename, PyCompilerFlags *flags)
+.. cfunction:: int PyRun_InteractiveLoopFlags(FILE *fp, const char *filename, PyCompilerFlags *flags)
 
    Read and execute statements from a file associated with an interactive device
-   until EOF is reached.  If *filename* is *NULL*, ``"???"`` is used instead.  The
-   user will be prompted using ``sys.ps1`` and ``sys.ps2``.  Returns ``0`` at EOF.
+   until EOF is reached.  The user will be prompted using ``sys.ps1`` and
+   ``sys.ps2``.  Returns ``0`` at EOF.
 
 
 .. cfunction:: struct _node* PyParser_SimpleParseString(const char *str, int start)

Doc/faq/windows.rst

@@ -290,20 +290,18 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
 
 1. Do _not_ build Python into your .exe file directly.  On Windows, Python must
    be a DLL to handle importing modules that are themselves DLL's.  (This is the
-   first key undocumented fact.) Instead, link to :file:`python{NN}.dll`; it is
-   typically installed in ``C:\Windows\System``.  NN is the Python version, a
+   first key undocumented fact.)  Instead, link to :file:`python{NN}.dll`; it is
+   typically installed in ``C:\Windows\System``.  *NN* is the Python version, a
    number such as "23" for Python 2.3.
 
-   You can link to Python statically or dynamically.  Linking statically means
-   linking against :file:`python{NN}.lib`, while dynamically linking means
-   linking against :file:`python{NN}.dll`.  The drawback to dynamic linking is
-   that your app won't run if :file:`python{NN}.dll` does not exist on your
-   system.  (General note: :file:`python{NN}.lib` is the so-called "import lib"
-   corresponding to :file:`python.dll`.  It merely defines symbols for the
-   linker.)
+   You can link to Python in two different ways.  Load-time linking means
+   linking against :file:`python{NN}.lib`, while run-time linking means linking
+   against :file:`python{NN}.dll`.  (General note: :file:`python{NN}.lib` is the
+   so-called "import lib" corresponding to :file:`python{NN}.dll`.  It merely
+   defines symbols for the linker.)
 
-   Linking dynamically greatly simplifies link options; everything happens at
-   run time.  Your code must load :file:`python{NN}.dll` using the Windows
+   Run-time linking greatly simplifies link options; everything happens at run
+   time.  Your code must load :file:`python{NN}.dll` using the Windows
    ``LoadLibraryEx()`` routine.  The code must also use access routines and data
    in :file:`python{NN}.dll` (that is, Python's C API's) using pointers obtained
    by the Windows ``GetProcAddress()`` routine.  Macros can make using these
@@ -312,6 +310,8 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
    Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf.exe
    first.
 
+   .. XXX what about static linking?
+
 2. If you use SWIG, it is easy to create a Python "extension module" that will
    make the app's data and methods available to Python.  SWIG will handle just
    about all the grungy details for you.  The result is C code that you link

Doc/howto/cporting.rst

@@ -50,9 +50,9 @@ Python 3.0's :func:`str` (``PyString_*`` functions in C) type is equivalent to
 compatibility with 3.0, :ctype:`PyUnicode` should be used for textual data and
 :ctype:`PyBytes` for binary data.  It's also important to remember that
 :ctype:`PyBytes` and :ctype:`PyUnicode` in 3.0 are not interchangeable like
-:ctype:`PyString` and :ctype:`PyString` are in 2.x.  The following example shows
-best practices with regards to :ctype:`PyUnicode`, :ctype:`PyString`, and
-:ctype:`PyBytes`. ::
+:ctype:`PyString` and :ctype:`PyUnicode` are in 2.x.  The following example
+shows best practices with regards to :ctype:`PyUnicode`, :ctype:`PyString`,
+and :ctype:`PyBytes`. ::
 
    #include "stdlib.h"
    #include "Python.h"

Doc/library/audioop.rst

@@ -230,8 +230,8 @@ and recombined later.  Here is an example of how to do that::
    def mul_stereo(sample, width, lfactor, rfactor):
        lsample = audioop.tomono(sample, width, 1, 0)
        rsample = audioop.tomono(sample, width, 0, 1)
-       lsample = audioop.mul(sample, width, lfactor)
-       rsample = audioop.mul(sample, width, rfactor)
+       lsample = audioop.mul(lsample, width, lfactor)
+       rsample = audioop.mul(rsample, width, rfactor)
        lsample = audioop.tostereo(lsample, width, 1, 0)
        rsample = audioop.tostereo(rsample, width, 0, 1)
        return audioop.add(lsample, rsample, width)

Doc/library/base64.rst

@@ -157,12 +157,12 @@ The legacy interface:
 An example usage of the module:
 
    >>> import base64
-   >>> encoded = base64.b64encode('data to be encoded')
+   >>> encoded = base64.b64encode(b'data to be encoded')
    >>> encoded
    b'ZGF0YSB0byBiZSBlbmNvZGVk'
    >>> data = base64.b64decode(encoded)
    >>> data
-   'data to be encoded'
+   b'data to be encoded'
 
 
 .. seealso::

Doc/library/difflib.rst

@@ -500,16 +500,11 @@ The :class:`SequenceMatcher` class has this constructor:
 
       Return an upper bound on :meth:`ratio` relatively quickly.
 
-      This isn't defined beyond that it is an upper bound on :meth:`ratio`, and
-      is faster to compute.
-
 
    .. method:: real_quick_ratio()
 
       Return an upper bound on :meth:`ratio` very quickly.
 
-      This isn't defined beyond that it is an upper bound on :meth:`ratio`, and
-      is faster to compute than either :meth:`ratio` or :meth:`quick_ratio`.
 
 The three methods that return the ratio of matching to total characters can give
 different results due to differing levels of approximation, although

Doc/library/dis.rst

@@ -93,7 +93,7 @@ The :mod:`dis` module defines the following functions and constants:
 
 .. data:: opmap
 
-   Dictionary mapping bytecodes to operation names.
+   Dictionary mapping operation names to bytecodes.
 
 
 .. data:: cmp_op

Doc/library/functions.rst

@@ -466,7 +466,7 @@ are always available.  They are listed here in alphabetical order.
 
 .. function:: getattr(object, name[, default])
 
-   Return the value of the named attributed of *object*.  *name* must be a string.
+   Return the value of the named attribute of *object*.  *name* must be a string.
    If the string is the name of one of the object's attributes, the result is the
    value of that attribute.  For example, ``getattr(x, 'foobar')`` is equivalent to
    ``x.foobar``.  If the named attribute does not exist, *default* is returned if

Doc/library/hmac.rst

@@ -2,7 +2,8 @@
 ========================================================
 
 .. module:: hmac
-   :synopsis: Keyed-Hashing for Message Authentication (HMAC) implementation for Python.
+   :synopsis: Keyed-Hashing for Message Authentication (HMAC) implementation
+              for Python.
 .. moduleauthor:: Gerhard Häring <ghaering@users.sourceforge.net>
 .. sectionauthor:: Gerhard Häring <ghaering@users.sourceforge.net>
 
@@ -12,37 +13,34 @@ This module implements the HMAC algorithm as described by :rfc:`2104`.
 
 .. function:: new(key, msg=None, digestmod=None)
 
-   Return a new hmac object.  If *msg* is present, the method call ``update(msg)``
-   is made. *digestmod* is the digest constructor or module for the HMAC object to
-   use. It defaults to  the :func:`hashlib.md5` constructor.
+   Return a new hmac object.  *key* is a bytes object giving the secret key.  If
+   *msg* is present, the method call ``update(msg)`` is made.  *digestmod* is
+   the digest constructor or module for the HMAC object to use. It defaults to
+   the :func:`hashlib.md5` constructor.
 
-   .. note::
-
-      The md5 hash has known weaknesses but remains the default for backwards
-      compatibility. Choose a better one for your application.
 
 An HMAC object has the following methods:
 
-
 .. method:: hmac.update(msg)
 
-   Update the hmac object with the string *msg*.  Repeated calls are equivalent to
-   a single call with the concatenation of all the arguments: ``m.update(a);
-   m.update(b)`` is equivalent to ``m.update(a + b)``.
+   Update the hmac object with the bytes object *msg*.  Repeated calls are
+   equivalent to a single call with the concatenation of all the arguments:
+   ``m.update(a); m.update(b)`` is equivalent to ``m.update(a + b)``.
 
 
 .. method:: hmac.digest()
 
-   Return the digest of the strings passed to the :meth:`update` method so far.
-   This string will be the same length as the *digest_size* of the digest given to
-   the constructor.  It may contain non-ASCII characters, including NUL bytes.
+   Return the digest of the bytes passed to the :meth:`update` method so far.
+   This bytes object will be the same length as the *digest_size* of the digest
+   given to the constructor.  It may contain non-ASCII bytes, including NUL
+   bytes.
 
 
 .. method:: hmac.hexdigest()
 
-   Like :meth:`digest` except the digest is returned as a string twice the length
-   containing only hexadecimal digits.  This may be used to exchange the value
-   safely in email or other non-binary environments.
+   Like :meth:`digest` except the digest is returned as a string twice the
+   length containing only hexadecimal digits.  This may be used to exchange the
+   value safely in email or other non-binary environments.
 
 
 .. method:: hmac.copy()
@@ -55,4 +53,3 @@ An HMAC object has the following methods:
 
    Module :mod:`hashlib`
       The Python module providing secure hash functions.
-

Doc/library/os.rst

@@ -1421,15 +1421,15 @@ to be ignored.
 
 .. function:: _exit(n)
 
-   Exit to the system with status *n*, without calling cleanup handlers, flushing
+   Exit the process with status *n*, without calling cleanup handlers, flushing
    stdio buffers, etc.
 
    Availability: Unix, Windows.
 
    .. note::
 
-      The standard way to exit is ``sys.exit(n)``. :func:`_exit` should normally only
-      be used in the child process after a :func:`fork`.
+      The standard way to exit is ``sys.exit(n)``.  :func:`_exit` should
+      normally only be used in the child process after a :func:`fork`.
 
 The following exit codes are defined and can be used with :func:`_exit`,
 although they are not required.  These are typically used for system programs

Doc/library/shelve.rst

@@ -43,6 +43,11 @@ lots of shared  sub-objects.  The keys are ordinary strings.
       :meth:`close` explicitly when you don't need it any more, or use a
       :keyword:`with` statement with :func:`contextlib.closing`.
 
+.. warning::
+
+   Because the :mod:`shelve` module is backed by :mod:`pickle`, it is insecure
+   to load a shelf from an untrusted source.  Like with pickle, loading a shelf
+   can execute arbitrary code.
 
 Shelf objects support all methods supported by dictionaries.  This eases the
 transition from dictionary based scripts to those requiring persistent storage.

Doc/library/sqlite3.rst

@@ -255,23 +255,22 @@ Connection Objects
 .. method:: Connection.execute(sql, [parameters])
 
    This is a nonstandard shortcut that creates an intermediate cursor object by
-   calling the cursor method, then calls the cursor's
-   :meth:`execute<Cursor.execute>` method with the parameters given.
+   calling the cursor method, then calls the cursor's :meth:`execute
+   <Cursor.execute>` method with the parameters given.
 
 
 .. method:: Connection.executemany(sql, [parameters])
 
    This is a nonstandard shortcut that creates an intermediate cursor object by
-   calling the cursor method, then calls the cursor's
-   :meth:`executemany<Cursor.executemany>` method with the parameters given.
+   calling the cursor method, then calls the cursor's :meth:`executemany
+   <Cursor.executemany>` method with the parameters given.
 
 
 .. method:: Connection.executescript(sql_script)
 
    This is a nonstandard shortcut that creates an intermediate cursor object by
-   calling the cursor method, then calls the cursor's
-   :meth:`executescript<Cursor.executescript>` method with the parameters
-   given.
+   calling the cursor method, then calls the cursor's :meth:`executescript
+   <Cursor.executescript>` method with the parameters given.
 
 
 .. method:: Connection.create_function(name, num_params, func)
@@ -435,7 +434,7 @@ Cursor Objects
 
 .. class:: Cursor
 
-   A SQLite database cursor has the following attributes and methods:
+   A :class:`Cursor` instance has the following attributes and methods.
 
 .. method:: Cursor.execute(sql, [parameters])
 
@@ -853,4 +852,3 @@ threads. If you still try to do so, you will get an exception at runtime.
 
 The only exception is calling the :meth:`~Connection.interrupt` method, which
 only makes sense to call from a different thread.
-

Doc/library/stdtypes.rst

@@ -1264,9 +1264,8 @@ formats in the string *must* include a parenthesised mapping key into that
 dictionary inserted immediately after the ``'%'`` character. The mapping key
 selects the value to be formatted from the mapping.  For example:
 
-
-   >>> print('%(language)s has %(#)03d quote types.' % \
-   ...       {'language': "Python", "#": 2})
+   >>> print('%(language)s has %(number)03d quote types.' %
+   ...       {'language': "Python", "number": 2})
    Python has 002 quote types.
 
 In this case no ``*`` specifiers may occur in a format (since they require a
@@ -1877,12 +1876,12 @@ pairs within braces, for example: ``{'jack': 4098, 'sjoerd': 4127}`` or ``{4098:
    values are added as items to the dictionary.  If a key is specified both in
    the positional argument and as a keyword argument, the value associated with
    the keyword is retained in the dictionary.  For example, these all return a
-   dictionary equal to ``{"one": 2, "two": 3}``:
+   dictionary equal to ``{"one": 1, "two": 2}``:
 
-   * ``dict(one=2, two=3)``
-   * ``dict({'one': 2, 'two': 3})``
-   * ``dict(zip(('one', 'two'), (2, 3)))``
-   * ``dict([['two', 3], ['one', 2]])``
+   * ``dict(one=1, two=2)``
+   * ``dict({'one': 1, 'two': 2})``
+   * ``dict(zip(('one', 'two'), (1, 2)))``
+   * ``dict([['two', 2], ['one', 1]])``
 
    The first example only works for keys that are valid Python identifiers; the
    others work with any valid keys.

Doc/library/sys.rst

@@ -48,6 +48,13 @@ always available.
    ``modules.keys()`` only lists the imported modules.)
 
 
+.. function:: call_tracing(func, args)
+
+   Call ``func(*args)``, while tracing is enabled.  The tracing state is saved,
+   and restored afterwards.  This is intended to be called from a debugger from
+   a checkpoint, to recursively debug some other code.
+
+
 .. data:: copyright
 
    A string containing the copyright pertaining to the Python interpreter.
@@ -173,19 +180,25 @@ always available.
 
    Exit from Python.  This is implemented by raising the :exc:`SystemExit`
    exception, so cleanup actions specified by finally clauses of :keyword:`try`
-   statements are honored, and it is possible to intercept the exit attempt at an
-   outer level.  The optional argument *arg* can be an integer giving the exit
-   status (defaulting to zero), or another type of object.  If it is an integer,
-   zero is considered "successful termination" and any nonzero value is considered
-   "abnormal termination" by shells and the like.  Most systems require it to be in
-   the range 0-127, and produce undefined results otherwise.  Some systems have a
-   convention for assigning specific meanings to specific exit codes, but these are
-   generally underdeveloped; Unix programs generally use 2 for command line syntax
-   errors and 1 for all other kind of errors.  If another type of object is passed,
-   ``None`` is equivalent to passing zero, and any other object is printed to
-   ``sys.stderr`` and results in an exit code of 1.  In particular,
-   ``sys.exit("some error message")`` is a quick way to exit a program when an
-   error occurs.
+   statements are honored, and it is possible to intercept the exit attempt at
+   an outer level.
+
+   The optional argument *arg* can be an integer giving the exit status
+   (defaulting to zero), or another type of object.  If it is an integer, zero
+   is considered "successful termination" and any nonzero value is considered
+   "abnormal termination" by shells and the like.  Most systems require it to be
+   in the range 0-127, and produce undefined results otherwise.  Some systems
+   have a convention for assigning specific meanings to specific exit codes, but
+   these are generally underdeveloped; Unix programs generally use 2 for command
+   line syntax errors and 1 for all other kind of errors.  If another type of
+   object is passed, ``None`` is equivalent to passing zero, and any other
+   object is printed to :data:`stderr` and results in an exit code of 1.  In
+   particular, ``sys.exit("some error message")`` is a quick way to exit a
+   program when an error occurs.
+
+   Since :func:`exit` ultimately "only" raises an exception, it will only exit
+   the process when called from the main thread, and the exception is not
+   intercepted.
 
 
 .. data:: flags

Doc/library/token.rst

@@ -12,8 +12,8 @@ in the Python distribution for the definitions of the names in the context of
 the language grammar.  The specific numeric values which the names map to may
 change between Python versions.
 
-This module also provides one data object and some functions.  The functions
-mirror definitions in the Python C header files.
+The module also provides a mapping from numeric codes to names and some
+functions.  The functions mirror definitions in the Python C header files.
 
 
 .. data:: tok_name
@@ -38,6 +38,65 @@ mirror definitions in the Python C header files.
    Return true if *x* is the marker indicating the end of input.
 
 
+The token constants are:
+
+.. data:: ENDMARKER
+          NAME
+          NUMBER
+          STRING
+          NEWLINE
+          INDENT
+          DEDENT
+          LPAR
+          RPAR
+          LSQB
+          RSQB
+          COLON
+          COMMA
+          SEMI
+          PLUS
+          MINUS
+          STAR
+          SLASH
+          VBAR
+          AMPER
+          LESS
+          GREATER
+          EQUAL
+          DOT
+          PERCENT
+          BACKQUOTE
+          LBRACE
+          RBRACE
+          EQEQUAL
+          NOTEQUAL
+          LESSEQUAL
+          GREATEREQUAL
+          TILDE
+          CIRCUMFLEX
+          LEFTSHIFT
+          RIGHTSHIFT
+          DOUBLESTAR
+          PLUSEQUAL
+          MINEQUAL
+          STAREQUAL
+          SLASHEQUAL
+          PERCENTEQUAL
+          AMPEREQUAL
+          VBAREQUAL
+          CIRCUMFLEXEQUAL
+          LEFTSHIFTEQUAL
+          RIGHTSHIFTEQUAL
+          DOUBLESTAREQUAL
+          DOUBLESLASH
+          DOUBLESLASHEQUAL
+          AT
+          OP
+          ERRORTOKEN
+          N_TOKENS
+          NT_OFFSET
+
+
 .. seealso::
 
    Module :mod:`parser`

Doc/reference/compound_stmts.rst

@@ -553,10 +553,9 @@ A class definition defines a class object (see section :ref:`types`):
 
 .. productionlist::
    classdef: [`decorators`] "class" `classname` [`inheritance`] ":" `suite`
-   inheritance: "(" [`argument_list` [","] ] ")"
+   inheritance: "(" [`argument_list` [","] | `comprehension`] ")"
    classname: `identifier`
 
-
 A class definition is an executable statement.  The inheritance list usually
 gives a list of base classes (see :ref:`metaclasses` for more advanced uses), so
 each item in the list should evaluate to a class object which allows
@@ -582,7 +581,7 @@ namespace.
 
 Class creation can be customized heavily using :ref:`metaclasses <metaclasses>`.
 
-Classes can also be decorated; as with functions, ::
+Classes can also be decorated: just like when decorating functions, ::
 
    @f1(arg)
    @f2
@@ -593,6 +592,10 @@ is equivalent to ::
    class Foo: pass
    Foo = f1(arg)(f2(Foo))
 
+The evaluation rules for the decorator expressions are the same as for function
+decorators.  The result must be a class object, which is then bound to the class
+name.
+
 **Programmer's note:** Variables defined in the class definition are class
 attributes; they are shared by instances.  Instance attributes can be set in a
 method with ``self.name = value``.  Both class and instance attributes are

Doc/tutorial/classes.rst

@@ -4,26 +4,26 @@
 Classes
 *******
 
-Python's class mechanism adds classes to the language with a minimum of new
-syntax and semantics.  It is a mixture of the class mechanisms found in C++ and
-Modula-3.  As is true for modules, classes in Python do not put an absolute
-barrier between definition and user, but rather rely on the politeness of the
-user not to "break into the definition."  The most important features of classes
-are retained with full power, however: the class inheritance mechanism allows
+Compared with other programming languages, Python's class mechanism adds classes
+with a minimum of new syntax and semantics.  It is a mixture of the class
+mechanisms found in C++ and Modula-3.  Python classes provide all the standard
+features of Object Oriented Programming: the class inheritance mechanism allows
 multiple base classes, a derived class can override any methods of its base
 class or classes, and a method can call the method of a base class with the same
-name.  Objects can contain an arbitrary amount of data.
+name.  Objects can contain arbitrary amounts and kinds of data.  As is true for
+modules, classes partake of the dynamic nature of Python: they are created at
+runtime, and can be modified further after creation.
 
 In C++ terminology, normally class members (including the data members) are
-*public* (except see below :ref:`tut-private`),
-and all member functions are *virtual*.  As in Modula-3, there are no shorthands
-for referencing the object's members from its methods: the method function is
-declared with an explicit first argument representing the object, which is
-provided implicitly by the call.  As in Smalltalk, classes themselves are
-objects.  This provides semantics for importing and renaming.  Unlike C++ and
-Modula-3, built-in types can be used as base classes for extension by the user.
-Also, like in C++, most built-in operators with special syntax (arithmetic
-operators, subscripting etc.) can be redefined for class instances.
+*public* (except see below :ref:`tut-private`), and all member functions are
+*virtual*.  As in Modula-3, there are no shorthands for referencing the object's
+members from its methods: the method function is declared with an explicit first
+argument representing the object, which is provided implicitly by the call.  As
+in Smalltalk, classes themselves are objects.  This provides semantics for
+importing and renaming.  Unlike C++ and Modula-3, built-in types can be used as
+base classes for extension by the user.  Also, like in C++, most built-in
+operators with special syntax (arithmetic operators, subscripting etc.) can be
+redefined for class instances.
 
 (Lacking universally accepted terminology to talk about classes, I will make
 occasional use of Smalltalk and C++ terms.  I would use Modula-3 terms, since

Doc/using/windows.rst

@@ -156,23 +156,48 @@ installation directory.  So, if you had installed Python to
 :file:`C:\\Python\\Lib\\` and third-party modules should be stored in
 :file:`C:\\Python\\Lib\\site-packages\\`.
 
-.. `` this fixes syntax highlighting errors in some editors due to the \\ hackery
-
-You can add folders to your search path to make Python's import mechanism search
-in these directories as well.  Use :envvar:`PYTHONPATH`, as described in
-:ref:`using-on-envvars`, to modify :data:`sys.path`.  On Windows, paths are
-separated by semicolons, though, to distinguish them from drive identifiers
-(:file:`C:\\` etc.).
-
-.. ``
-
-Modifying the module search path can also be done through the Windows registry
-under the key :file:`HKLM\\SOFTWARE\\Python\\PythonCore\\{version}\\PythonPath`.
-Subkeys which have semicolon-delimited path strings as their default value will
-cause each path to be searched.  Multiple subkeys can be created and are
-appended to the path in alphabetical order.  A convenient registry editor is
-:program:`regedit` (start it by typing "regedit" into :menuselection:`Start -->
-Run`).
+This is how :data:`sys.path` is populated on Windows:
+
+* An empty entry is added at the start, which corresponds to the current
+  directory.
+
+* If the environment variable :envvar:`PYTHONPATH` exists, as described in
+  :ref:`using-on-envvars`, its entries are added next.  Note that on Windows,
+  paths in this variable must be separated by semicolons, to distinguish them
+  from the colon used in drive identifiers (``C:\`` etc.).
+
+* Additional "application paths" can be added in the registry as subkeys of
+  :samp:`\\SOFTWARE\\Python\\PythonCore\\{version}\\PythonPath` under both the
+  ``HKEY_CURRENT_USER`` and ``HKEY_LOCAL_MACHINE`` hives.  Subkeys which have
+  semicolon-delimited path strings as their default value will cause each path
+  to be added to :data:`sys.path`.  (Note that all known installers only use
+  HKLM, so HKCU is typically empty.)
+
+* If the environment variable :envvar:`PYTHONHOME` is set, it is assumed as
+  "Python Home".  Otherwise, the path of the main Python executable is used to
+  locate a "landmark file" (``Lib\os.py``) to deduce the "Python Home".  If a
+  Python home is found, the relevant sub-directories added to :data:`sys.path`
+  (``Lib``, ``plat-win``, etc) are based on that folder.  Otherwise, the core
+  Python path is constructed from the PythonPath stored in the registry.
+
+* If the Python Home cannot be located, no :envvar:`PYTHONPATH` is specified in
+  the environment, and no registry entries can be found, a default path with
+  relative entries is used (e.g. ``.\Lib;.\plat-win``, etc).
+
+The end result of all this is:
+
+* When running :file:`python.exe`, or any other .exe in the main Python
+  directory (either an installed version, or directly from the PCbuild
+  directory), the core path is deduced, and the core paths in the registry are
+  ignored.  Other "application paths" in the registry are always read.
+
+* When Python is hosted in another .exe (different directory, embedded via COM,
+  etc), the "Python Home" will not be deduced, so the core path from the
+  registry is used.  Other "application paths" in the registry are always read.
+
+* If Python can't find its home and there is no registry (eg, frozen .exe, some
+  very strange installation setup) you get a path with some default, but
+  relative, paths.
 
 
 Executing scripts