Commits

larry committed eedbf20 Merge

Pull and merge with Argument Clinic work.

Comments (0)

Files changed (858)

 .gdb_history
 .purify
 .svn/
+DS_Store
 Makefile$
 Makefile.pre$
 TAGS$
 pyconfig.h$
 python$
 python.exe$
+python-config$
+python-config.py$
 reflog.txt$
 tags$
 Lib/plat-mac/errors.rsrc.df.rsrc
 Doc/tools/jinja2/
 Doc/tools/pygments/
 Misc/python.pc
+Misc/python-config.sh$
 Modules/Setup$
 Modules/Setup.config
 Modules/Setup.local
 # Define dependencies of generated files that are checked into hg.
 # The syntax of this file uses make rule dependencies, without actions
 
-Python/importlib.h: Lib/importlib/_bootstrap.py Python/freeze_importlib.py
+Python/importlib.h: Lib/importlib/_bootstrap.py Modules/_freeze_importlib.c
 
 Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py
 Python/Python-ast.c: Include/ast.h
 
 Python/opcode_targets.h: Python/makeopcodetargets.py Lib/opcode.py
 
-Objects/typeslots.inc: Include/typeslots.h Objects/typeslots.py
+Objects/typeslots.inc: Include/typeslots.h Objects/typeslots.py
 as long as you don't change or remove the copyright notice:
 
 ----------------------------------------------------------------------
-Copyright (c) 2000-2012 Python Software Foundation.
+Copyright (c) 2000-2013 Python Software Foundation.
 All rights reserved.
 
 Copyright (c) 2000 BeOpen.com.

Doc/copyright.rst

 
 Python and this documentation is:
 
-Copyright © 2001-2012 Python Software Foundation. All rights reserved.
+Copyright © 2001-2013 Python Software Foundation. All rights reserved.
 
 Copyright © 2000 BeOpen.com. All rights reserved.
 

Doc/distutils/apiref.rst

    destination of the symlink will be copied.  *update* and *verbose* are the same
    as for :func:`copy_file`.
 
+   Files in *src* that begin with :file:`.nfs` are skipped (more information on
+   these files is available in answer D2 of the `NFS FAQ page
+   <http://nfs.sourceforge.net/#section_d>`_.
+
+   .. versionchanged:: 3.3.1
+      NFS files are ignored.
 
 .. function:: remove_tree(directory[, verbose=0, dry_run=0])
 

Doc/distutils/uploading.rst

 entered password. This is useful if you do not want to store a clear text
 password in the :file:`$HOME/.pypirc` file.
 
-You can specify another PyPI server with the :option:`--repository=*url*` option::
+You can specify another PyPI server with the ``--repository=url`` option::
 
     python setup.py sdist bdist_wininst upload -r http://example.com/pypi
 
 See section :ref:`pypirc` for more on defining several servers.
 
-You can use the :option:`--sign` option to tell :command:`upload` to sign each
+You can use the ``--sign`` option to tell :command:`upload` to sign each
 uploaded file using GPG (GNU Privacy Guard).  The  :program:`gpg` program must
 be available for execution on the system :envvar:`PATH`.  You can also specify
-which key to use for signing using the :option:`--identity=*name*` option.
+which key to use for signing using the ``--identity=name`` option.
 
-Other :command:`upload` options include :option:`--repository=<url>` or
-:option:`--repository=<section>` where *url* is the url of the server and
+Other :command:`upload` options include ``--repository=url`` or
+``--repository=section`` where *url* is the url of the server and
 *section* the name of the section in :file:`$HOME/.pypirc`, and
-:option:`--show-response` (which displays the full response text from the PyPI
+``--show-response`` (which displays the full response text from the PyPI
 server for help in debugging upload problems).
 
 PyPI package display

Doc/faq/design.rst

 generic for a group of types and which were intended to work even for objects
 that didn't have methods at all (e.g. tuples).  It is also convenient to have a
 function that can readily be applied to an amorphous collection of objects when
-you use the functional features of Python (``map()``, ``apply()`` et al).
+you use the functional features of Python (``map()``, ``zip()`` et al).
 
 In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in function is
 actually less code than implementing them as methods for each type.  One can
 
 Answer 2: Fortunately, there is `Stackless Python <http://www.stackless.com>`_,
 which has a completely redesigned interpreter loop that avoids the C stack.
-It's still experimental but looks very promising.  Although it is binary
-compatible with standard Python, it's still unclear whether Stackless will make
-it into the core -- maybe it's just too revolutionary.
 
 
 Why can't lambda forms contain statements?
 requested again.  This is called "memoizing", and can be implemented like this::
 
    # Callers will never provide a third parameter for this function.
-   def expensive (arg1, arg2, _cache={}):
+   def expensive(arg1, arg2, _cache={}):
        if (arg1, arg2) in _cache:
            return _cache[(arg1, arg2)]
 
 reasonable uses of the "go" or "goto" constructs of C, Fortran, and other
 languages.  For example::
 
-   class label: pass  # declare a label
+   class label(Exception): pass  # declare a label
 
    try:
         ...
-        if (condition): raise label()  # goto label
+        if condition: raise label()  # goto label
         ...
    except label:  # where to goto
         pass

Doc/faq/library.rst

            try:
                c = sys.stdin.read(1)
                print("Got character", repr(c))
-           except IOError:
+           except OSError:
                pass
    finally:
        termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)
    :func:`termios.tcsetattr` turns off stdin's echoing and disables canonical
    mode.  :func:`fcntl.fnctl` is used to obtain stdin's file descriptor flags
    and modify them for non-blocking mode.  Since reading stdin when it is empty
-   results in an :exc:`IOError`, this error is caught and ignored.
+   results in an :exc:`OSError`, this error is caught and ignored.
+
+   .. versionchanged:: 3.3
+      *sys.stdin.read* used to raise :exc:`IOError`. Starting from Python 3.3
+      :exc:`IOError` is alias for :exc:`OSError`.
 
 
 Threads

Doc/faq/programming.rst

 declaration for identifying side-effects.
 
 
+Why do lambdas defined in a loop with different values all return the same result?
+----------------------------------------------------------------------------------
+
+Assume you use a for loop to define a few different lambdas (or even plain
+functions), e.g.::
+
+   squares = []
+   for x in range(5):
+      squares.append(lambda: x**2)
+
+This gives you a list that contains 5 lambdas that calculate ``x**2``.  You
+might expect that, when called, they would return, respectively, ``0``, ``1``,
+``4``, ``9``, and ``16``.  However, when you actually try you will see that
+they all return ``16``::
+
+   >>> squares[2]()
+   16
+   >>> squares[4]()
+   16
+
+This happens because ``x`` is not local to the lambdas, but is defined in
+the outer scope, and it is accessed when the lambda is called --- not when it
+is defined.  At the end of the loop, the value of ``x`` is ``4``, so all the
+functions now return ``4**2``, i.e. ``16``.  You can also verify this by
+changing the value of ``x`` and see how the results of the lambdas change::
+
+   >>> x = 8
+   >>> squares[2]()
+   64
+
+In order to avoid this, you need to save the values in variables local to the
+lambdas, so that they don't rely on the value of the global ``x``::
+
+   squares = []
+   for x in range(5):
+      squares.append(lambda n=x: n**2)
+
+Here, ``n=x`` creates a new variable ``n`` local to the lambda and computed
+when the lambda is defined so that it has the same value that ``x`` had at
+that point in the loop.  This means that the value of ``n`` will be ``0``
+in the first lambda, ``1`` in the second, ``2`` in the third, and so on.
+Therefore each lambda will now return the correct result::
+
+   >>> squares[2]()
+   4
+   >>> squares[4]()
+   16
+
+Note that this behaviour is not peculiar to lambdas, but applies to regular
+functions too.
+
+
 How do I share global variables across modules?
 ------------------------------------------------
 
        g(x, *args, **kwargs)
 
 
+.. index::
+   single: argument; difference from parameter
+   single: parameter; difference from argument
+
 .. _faq-argument-vs-parameter:
 
 What is the difference between arguments and parameters?

Doc/faq/windows.rst

 
 This is not necessarily a straightforward question. If you are already familiar
 with running programs from the Windows command line then everything will seem
-obvious; otherwise, you might need a little more guidance.  There are also
-differences between Windows 95, 98, NT, ME, 2000 and XP which can add to the
-confusion.
+obvious; otherwise, you might need a little more guidance.
 
 .. sidebar:: |Python Development on XP|_
    :subtitle: `Python Development on XP`_
 Unless you use some sort of integrated development environment, you will end up
 *typing* Windows commands into what is variously referred to as a "DOS window"
 or "Command prompt window".  Usually you can create such a window from your
-Start menu; under Windows 2000 the menu selection is :menuselection:`Start -->
+Start menu; under Windows 7 the menu selection is :menuselection:`Start -->
 Programs --> Accessories --> Command Prompt`.  You should be able to recognize
 when you have started such a window because you will see a Windows "command
 prompt", which usually looks like this::
 The letter may be different, and there might be other things after it, so you
 might just as easily see something like::
 
-   D:\Steve\Projects\Python>
+   D:\YourName\Projects\Python>
 
 depending on how your computer has been set up and what else you have recently
 done with it.  Once you have started such a window, you are well on the way to
 running Python programs.
 
 You need to realize that your Python scripts have to be processed by another
-program called the Python interpreter.  The interpreter reads your script,
+program called the Python *interpreter*.  The interpreter reads your script,
 compiles it into bytecodes, and then executes the bytecodes to run your
 program. So, how do you arrange for the interpreter to handle your Python?
 
 First, you need to make sure that your command window recognises the word
 "python" as an instruction to start the interpreter.  If you have opened a
 command window, you should try entering the command ``python`` and hitting
-return.  You should then see something like::
+return.::
 
-   Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32
+   C:\Users\YourName> python
+
+You should then see something like::
+
+   Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
 
 Windows command prompt.
 
 You may also find that you have a Start-menu entry such as :menuselection:`Start
---> Programs --> Python 2.2 --> Python (command line)` that results in you
+--> Programs --> Python 3.3 --> Python (command line)` that results in you
 seeing the ``>>>`` prompt in a new window.  If so, the window will disappear
 after you enter the Ctrl-Z character; Windows is running a single "python"
 command in the window, and closes it when you terminate the interpreter.
 If the ``python`` command, instead of displaying the interpreter prompt ``>>>``,
 gives you a message like::
 
-   'python' is not recognized as an internal or external command,
-   operable program or batch file.
+   'python' is not recognized as an internal or external command, operable program or batch file.
 
 .. sidebar:: |Adding Python to DOS Path|_
    :subtitle: `Adding Python to DOS Path`_
    dir C:\py*
 
 will probably tell you where it is installed; the usual location is something
-like ``C:\Python23``.  Otherwise you will be reduced to a search of your whole
+like ``C:\Python33``.  Otherwise you will be reduced to a search of your whole
 disk ... use :menuselection:`Tools --> Find` or hit the :guilabel:`Search`
 button and look for "python.exe".  Supposing you discover that Python is
-installed in the ``C:\Python23`` directory (the default at the time of writing),
+installed in the ``C:\Python33`` directory (the default at the time of writing),
 you should make sure that entering the command ::
 
-   c:\Python23\python
+   c:\Python33\python
 
 starts up the interpreter as above (and don't forget you'll need a "CTRL-Z" and
-an "Enter" to get out of it). Once you have verified the directory, you need to
-add it to the start-up routines your computer goes through.  For older versions
-of Windows the easiest way to do this is to edit the ``C:\AUTOEXEC.BAT``
-file. You would want to add a line like the following to ``AUTOEXEC.BAT``::
+an "Enter" to get out of it). Once you have verified the directory, you can
+add it to the system path to make it easier to start Python by just running
+the ``python`` command. This is currently an option in the installer as of
+CPython 3.3.
 
-   PATH C:\Python23;%PATH%
-
-For Windows NT, 2000 and (I assume) XP, you will need to add a string such as ::
-
-   ;C:\Python23
-
-to the current setting for the PATH environment variable, which you will find in
-the properties window of "My Computer" under the "Advanced" tab.  Note that if
-you have sufficient privilege you might get a choice of installing the settings
-either for the Current User or for System.  The latter is preferred if you want
-everybody to be able to run Python on the machine.
-
-If you aren't confident doing any of these manipulations yourself, ask for help!
-At this stage you may want to reboot your system to make absolutely sure the new
-setting has taken effect.  You probably won't need to reboot for Windows NT, XP
-or 2000.  You can also avoid it in earlier versions by editing the file
-``C:\WINDOWS\COMMAND\CMDINIT.BAT`` instead of ``AUTOEXEC.BAT``.
-
-You should now be able to start a new command window, enter ``python`` at the
-``C:\>`` (or whatever) prompt, and see the ``>>>`` prompt that indicates the
-Python interpreter is reading interactive commands.
-
-Let's suppose you have a program called ``pytest.py`` in directory
-``C:\Steve\Projects\Python``.  A session to run that program might look like
-this::
-
-   C:\> cd \Steve\Projects\Python
-   C:\Steve\Projects\Python> python pytest.py
-
-Because you added a file name to the command to start the interpreter, when it
-starts up it reads the Python script in the named file, compiles it, executes
-it, and terminates, so you see another ``C:\>`` prompt.  You might also have
-entered ::
-
-   C:\> python \Steve\Projects\Python\pytest.py
-
-if you hadn't wanted to change your current directory.
-
-Under NT, 2000 and XP you may well find that the installation process has also
-arranged that the command ``pytest.py`` (or, if the file isn't in the current
-directory, ``C:\Steve\Projects\Python\pytest.py``) will automatically recognize
-the ".py" extension and run the Python interpreter on the named file. Using this
-feature is fine, but *some* versions of Windows have bugs which mean that this
-form isn't exactly equivalent to using the interpreter explicitly, so be
-careful.
-
-The important things to remember are:
-
-1. Start Python from the Start Menu, or make sure the PATH is set correctly so
-   Windows can find the Python interpreter. ::
-
-      python
-
-   should give you a '>>>' prompt from the Python interpreter. Don't forget the
-   CTRL-Z and ENTER to terminate the interpreter (and, if you started the window
-   from the Start Menu, make the window disappear).
-
-2. Once this works, you run programs with commands::
-
-      python {program-file}
-
-3. When you know the commands to use you can build Windows shortcuts to run the
-   Python interpreter on any of your scripts, naming particular working
-   directories, and adding them to your menus.  Take a look at ::
-
-      python --help
-
-   if your needs are complex.
-
-4. Interactive mode (where you see the ``>>>`` prompt) is best used for checking
-   that individual statements and expressions do what you think they will, and
-   for developing code by experiment.
-
+More information about environment variables can be found on the
+:ref:`Using Python on Windows <setting-envvars>` page.
 
 How do I make Python scripts executable?
 ----------------------------------------
 
-On Windows 2000, the standard Python installer already associates the .py
+On Windows, the standard Python installer already associates the .py
 extension with a file type (Python.File) and gives that file type an open
 command that runs the interpreter (``D:\Program Files\Python\python.exe "%1"
 %*``).  This is enough to make scripts executable from the command prompt as
 'foo.py'.  If you'd rather be able to execute the script by simple typing 'foo'
 with no extension you need to add .py to the PATHEXT environment variable.
 
-On Windows NT, the steps taken by the installer as described above allow you to
-run a script with 'foo.py', but a longtime bug in the NT command processor
-prevents you from redirecting the input or output of any script executed in this
-way.  This is often important.
-
-The incantation for making a Python script executable under WinNT is to give the
-file an extension of .cmd and add the following as the first line::
-
-   @setlocal enableextensions & python -x %~f0 %* & goto :EOF
-
-
 Why does Python sometimes take so long to start?
 ------------------------------------------------
 
 offender.
 
 
-Where is Freeze for Windows?
-----------------------------
+How do I make an executable from a Python script?
+-------------------------------------------------
 
-"Freeze" is a program that allows you to ship a Python program as a single
-stand-alone executable file.  It is *not* a compiler; your programs don't run
-any faster, but they are more easily distributable, at least to platforms with
-the same OS and CPU.  Read the README file of the freeze program for more
-disclaimers.
-
-You can use freeze on Windows, but you must download the source tree (see
-http://www.python.org/download/source).  The freeze program is in the
-``Tools\freeze`` subdirectory of the source tree.
-
-You need the Microsoft VC++ compiler, and you probably need to build Python.
-The required project files are in the PCbuild directory.
-
+See http://www.py2exe.org/ for a distutils extension that allows you
+to create console and GUI executables from Python code.
 
 Is a ``*.pyd`` file the same as a DLL?
 --------------------------------------
    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
-   number such as "23" for Python 2.3.
+   number such as "33" for Python 3.3.
 
    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
    object that supports read and write, so all you need is a Python object
    (defined in your extension module) that contains read() and write() methods.
 
-
-How do I use Python for CGI?
-----------------------------
-
-On the Microsoft IIS server or on the Win95 MS Personal Web Server you set up
-Python in the same way that you would set up any other scripting engine.
-
-Run regedt32 and go to::
-
-    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
-
-and enter the following line (making any specific changes that your system may
-need)::
-
-    .py :REG_SZ: c:\<path to python>\python.exe -u %s %s
-
-This line will allow you to call your script with a simple reference like:
-``http://yourserver/scripts/yourscript.py`` provided "scripts" is an
-"executable" directory for your server (which it usually is by default).  The
-:option:`-u` flag specifies unbuffered and binary mode for stdin - needed when
-working with binary data.
-
-In addition, it is recommended that using ".py" may not be a good idea for the
-file extensions when used in this context (you might want to reserve ``*.py``
-for support modules and use ``*.cgi`` or ``*.cgp`` for "main program" scripts).
-
-In order to set up Internet Information Services 5 to use Python for CGI
-processing, please see the following links:
-
-   http://www.e-coli.net/pyiis_server.html (for Win2k Server)
-   http://www.e-coli.net/pyiis.html (for Win2k pro)
-
-Configuring Apache is much simpler.  In the Apache configuration file
-``httpd.conf``, add the following line at the end of the file::
-
-    ScriptInterpreterSource Registry
-
-Then, give your Python CGI-scripts the extension .py and put them in the cgi-bin
-directory.
-
-
 How do I keep editors from inserting tabs into my Python source?
 ----------------------------------------------------------------
 
 to console subprocesses which are designed to handle those signals. See
 :func:`os.kill` for further details.
 
-
-Why does os.path.isdir() fail on NT shared directories?
--------------------------------------------------------
-
-In order to work correctly, :func:`os.path.isdir` requires a ``"\\"`` at the
-end of the shared drive::
-
-   >>> import os
-   >>> os.path.isdir('\\\\rorschach\\public')
-   0
-   >>> os.path.isdir('\\\\rorschach\\public\\')
-   1
-
-It helps to think of share points as being like drive letters.  Example::
-
-   k: is not a directory
-   k:\ is a directory
-   k:\media is a directory
-   k:\media\ is not a directory
-
-The same rules apply if you substitute ``"k:"`` with ``"\\conky\foo"``::
-
-   \\conky\foo  is not a directory
-   \\conky\foo\ is a directory
-   \\conky\foo\media is a directory
-   \\conky\foo\media\ is not a directory
-
-
-cgi.py (or other CGI programming) doesn't work sometimes on NT or win95!
-------------------------------------------------------------------------
-
-Be sure you have the latest python.exe, that you are using python.exe rather
-than a GUI version of Python and that you have configured the server to execute
-::
-
-   "...\python.exe -u ..."
-
-for the CGI execution.  The :option:`-u` (unbuffered) option on NT and Win95
-prevents the interpreter from altering newlines in the standard input and
-output.  Without it post/multipart requests will seem to have the wrong length
-and binary (e.g. GIF) responses may get garbled (resulting in broken images, PDF
-files, and other binary downloads failing).
-
-
-Why doesn't os.popen() work in PythonWin on NT?
------------------------------------------------
-
-The reason that os.popen() doesn't work from within PythonWin is due to a bug in
-Microsoft's C Runtime Library (CRT). The CRT assumes you have a Win32 console
-attached to the process.
-
-You should use the win32pipe module's popen() instead which doesn't depend on
-having an attached Win32 console.
-
-Example::
-
-   import win32pipe
-   f = win32pipe.popen('dir /c c:\\')
-   print(f.readlines())
-   f.close()
-
-
-Why doesn't os.popen()/win32pipe.popen() work on Win9x?
--------------------------------------------------------
-
-There is a bug in Win9x that prevents os.popen/win32pipe.popen* from
-working. The good news is there is a way to work around this problem.  The
-Microsoft Knowledge Base article that you need to lookup is: Q150956. You will
-find links to the knowledge base at: http://support.microsoft.com/.
-
-
-PyRun_SimpleFile() crashes on Windows but not on Unix; why?
------------------------------------------------------------
-
-This is very sensitive to the compiler vendor, version and (perhaps) even
-options.  If the FILE* structure in your embedding program isn't the same as is
-assumed by the Python interpreter it won't work.
-
-The Python 1.5.* DLLs (``python15.dll``) are all compiled with MS VC++ 5.0 and
-with multithreading-DLL options (``/MD``).
-
-If you can't change compilers or flags, try using :c:func:`Py_RunSimpleString`.
-A trick to get it to run an arbitrary file is to construct a call to
-:func:`exec` and :func:`open` with the name of your file as argument.
-
-Also note that you can not mix-and-match Debug and Release versions.  If you
-wish to use the Debug Multithreaded DLL, then your module *must* have ``_d``
-appended to the base name.
-
-
-Importing _tkinter fails on Windows 95/98: why?
-------------------------------------------------
-
-Sometimes, the import of _tkinter fails on Windows 95 or 98, complaining with a
-message like the following::
-
-   ImportError: DLL load failed: One of the library files needed
-   to run this application cannot be found.
-
-It could be that you haven't installed Tcl/Tk, but if you did install Tcl/Tk,
-and the Wish application works correctly, the problem may be that its installer
-didn't manage to edit the autoexec.bat file correctly.  It tries to add a
-statement that changes the PATH environment variable to include the Tcl/Tk 'bin'
-subdirectory, but sometimes this edit doesn't quite work.  Opening it with
-notepad usually reveals what the problem is.
-
-(One additional hint, noted by David Szafranski: you can't use long filenames
-here; e.g. use ``C:\PROGRA~1\Tcl\bin`` instead of ``C:\Program Files\Tcl\bin``.)
-
-
 How do I extract the downloaded documentation on Windows?
 ---------------------------------------------------------
 
 able to handle it.  (If your copy of WinZip doesn't, get a newer one from
 http://www.winzip.com.)
 
-
-Missing cw3215mt.dll (or missing cw3215.dll)
---------------------------------------------
-
-Sometimes, when using Tkinter on Windows, you get an error that cw3215mt.dll or
-cw3215.dll is missing.
-
-Cause: you have an old Tcl/Tk DLL built with cygwin in your path (probably
-``C:\Windows``).  You must use the Tcl/Tk DLLs from the standard Tcl/Tk
-installation (Python 1.5.2 comes with one).
-
-
-Warning about CTL3D32 version from installer
---------------------------------------------
-
-The Python installer issues a warning like this::
-
-   This version uses CTL3D32.DLL which is not the correct version.
-   This version is used for windows NT applications only.
-
-Tim Peters:
-
-   This is a Microsoft DLL, and a notorious source of problems.  The message
-   means what it says: you have the wrong version of this DLL for your operating
-   system.  The Python installation did not cause this -- something else you
-   installed previous to this overwrote the DLL that came with your OS (probably
-   older shareware of some sort, but there's no way to tell now).  If you search
-   for "CTL3D32" using any search engine (AltaVista, for example), you'll find
-   hundreds and hundreds of web pages complaining about the same problem with
-   all sorts of installation programs.  They'll point you to ways to get the
-   correct version reinstalled on your system (since Python doesn't cause this,
-   we can't fix it).
-
-David A Burton has written a little program to fix this.  Go to
-http://www.burtonsys.com/downloads.html and click on "ctl3dfix.zip".
 
    function
       A series of statements which returns some value to a caller. It can also
-      be passed zero or more arguments which may be used in the execution of
-      the body. See also :term:`argument` and :term:`method`.
+      be passed zero or more :term:`arguments <argument>` which may be used in
+      the execution of the body. See also :term:`parameter`, :term:`method`,
+      and the :ref:`function` section.
 
    __future__
       A pseudo-module which programmers can use to enable new language features
       All of Python's immutable built-in objects are hashable, while no mutable
       containers (such as lists or dictionaries) are.  Objects which are
       instances of user-defined classes are hashable by default; they all
-      compare unequal, and their hash value is their :func:`id`.
+      compare unequal (except with themselves), and their hash value is their
+      :func:`id`.
 
    IDLE
       An Integrated Development Environment for Python.  IDLE is a basic editor
       slowly.  See also :term:`interactive`.
 
    iterable
-      An object capable of returning its members one at a
-      time. Examples of iterables include all sequence types (such as
-      :class:`list`, :class:`str`, and :class:`tuple`) and some non-sequence
-      types like :class:`dict` and :class:`file` and objects of any classes you
-      define with an :meth:`__iter__` or :meth:`__getitem__` method.  Iterables
-      can be used in a :keyword:`for` loop and in many other places where a
-      sequence is needed (:func:`zip`, :func:`map`, ...).  When an iterable
-      object is passed as an argument to the built-in function :func:`iter`, it
-      returns an iterator for the object.  This iterator is good for one pass
-      over the set of values.  When using iterables, it is usually not necessary
-      to call :func:`iter` or deal with iterator objects yourself.  The ``for``
+      An object capable of returning its members one at a time. Examples of
+      iterables include all sequence types (such as :class:`list`, :class:`str`,
+      and :class:`tuple`) and some non-sequence types like :class:`dict`,
+      :term:`file objects <file object>`, and objects of any classes you define
+      with an :meth:`__iter__` or :meth:`__getitem__` method.  Iterables can be
+      used in a :keyword:`for` loop and in many other places where a sequence is
+      needed (:func:`zip`, :func:`map`, ...).  When an iterable object is passed
+      as an argument to the built-in function :func:`iter`, it returns an
+      iterator for the object.  This iterator is good for one pass over the set
+      of values.  When using iterables, it is usually not necessary to call
+      :func:`iter` or deal with iterator objects yourself.  The ``for``
       statement does that automatically for you, creating a temporary unnamed
       variable to hold the iterator for the duration of the loop.  See also
       :term:`iterator`, :term:`sequence`, and :term:`generator`.

Doc/howto/argparse.rst

 Argparse Tutorial
 *****************
 
-:author: Tshepang Lekhonkhobe <tshepang@gmail.com>
+:author: Tshepang Lekhonkhobe
 
 .. _argparse-tutorial:
 

Doc/howto/cporting.rst

 used in Python 2 was removed.  In the C-API, ``PyInt_*`` functions
 are replaced by their ``PyLong_*`` equivalents.
 
-The best course of action here is using the ``PyInt_*`` functions aliased to
-``PyLong_*`` found in :file:`intobject.h`.  The abstract ``PyNumber_*`` APIs
-can also be used in some cases. ::
-
-   #include "Python.h"
-   #include "intobject.h"
-
-   static PyObject *
-   add_ints(PyObject *self, PyObject *args) {
-       int one, two;
-       PyObject *result;
-
-       if (!PyArg_ParseTuple(args, "ii:add_ints", &one, &two))
-           return NULL;
-
-       return PyInt_FromLong(one + two);
-   }
-
-
 
 Module initialization and state
 ===============================
 
   * :c:func:`PyCapsule_GetName` always returns NULL.
 
-  * :c:func:`PyCapsule_SetName` always throws an exception and
+  * :c:func:`PyCapsule_SetName` always raises an exception and
     returns failure.  (Since there's no way to store a name
     in a CObject, noisy failure of :c:func:`PyCapsule_SetName`
     was deemed preferable to silent failure here.  If this is

Doc/howto/functional.rst

 You could equally write ``for i in generate_ints(5)``, or ``a,b,c =
 generate_ints(3)``.
 
-Inside a generator function, the ``return`` statement can only be used without a
-value, and signals the end of the procession of values; after executing a
-``return`` the generator cannot return any further values.  ``return`` with a
-value, such as ``return 5``, is a syntax error inside a generator function.  The
-end of the generator's results can also be indicated by raising
-:exc:`StopIteration` manually, or by just letting the flow of execution fall off
-the bottom of the function.
+Inside a generator function, ``return value`` is semantically equivalent to
+``raise StopIteration(value)``.  If no value is returned or the bottom of the
+function is reached, the procession of values ends and the generator cannot
+return any further values.
 
 You could achieve the effect of generators manually by writing your own class
 and storing all the local variables of the generator as instance variables.  For

Doc/howto/logging-cookbook.rst

 RFC 5424-compliant messages. If you don't, logging may not complain, but your
 messages will not be RFC 5424-compliant, and your syslog daemon may complain.
 
+
+Implementing structured logging
+-------------------------------
+
+Although most logging messages are intended for reading by humans, and thus not
+readily machine-parseable, there might be cirumstances where you want to output
+messages in a structured format which *is* capable of being parsed by a program
+(without needing complex regular expressions to parse the log message). This is
+straightforward to achieve using the logging package. There are a number of
+ways in which this could be achieved, but the following is a simple approach
+which uses JSON to serialise the event in a machine-parseable manner::
+
+    import json
+    import logging
+
+    class StructuredMessage(object):
+        def __init__(self, message, **kwargs):
+            self.message = message
+            self.kwargs = kwargs
+
+        def __str__(self):
+            return '%s >>> %s' % (self.message, json.dumps(self.kwargs))
+
+    _ = StructuredMessage   # optional, to improve readability
+
+    logging.basicConfig(level=logging.INFO, format='%(message)s')
+    logging.info(_('message 1', foo='bar', bar='baz', num=123, fnum=123.456))
+
+If the above script is run, it prints::
+
+    message 1 >>> {"fnum": 123.456, "num": 123, "bar": "baz", "foo": "bar"}
+
+Note that the order of items might be different according to the version of
+Python used.
+
+If you need more specialised processing, you can use a custom JSON encoder,
+as in the following complete example::
+
+    from __future__ import unicode_literals
+
+    import json
+    import logging
+
+    # This next bit is to ensure the script runs unchanged on 2.x and 3.x
+    try:
+        unicode
+    except NameError:
+        unicode = str
+
+    class Encoder(json.JSONEncoder):
+        def default(self, o):
+            if isinstance(o, set):
+                return tuple(o)
+            elif isinstance(o, unicode):
+                return o.encode('unicode_escape').decode('ascii')
+            return super(Encoder, self).default(o)
+
+    class StructuredMessage(object):
+        def __init__(self, message, **kwargs):
+            self.message = message
+            self.kwargs = kwargs
+
+        def __str__(self):
+            s = Encoder().encode(self.kwargs)
+            return '%s >>> %s' % (self.message, s)
+
+    _ = StructuredMessage   # optional, to improve readability
+
+    def main():
+        logging.basicConfig(level=logging.INFO, format='%(message)s')
+        logging.info(_('message 1', set_value=set([1, 2, 3]), snowman='\u2603'))
+
+    if __name__ == '__main__':
+        main()
+
+When the above script is run, it prints::
+
+    message 1 >>> {"snowman": "\u2603", "set_value": [1, 2, 3]}
+
+Note that the order of items might be different according to the version of
+Python used.
+

Doc/howto/logging.rst

   to output.
 * Formatters specify the layout of log records in the final output.
 
+Log event information is passed between loggers, handlers, filters and
+formatters in a :class:`LogRecord` instance.
+
 Logging is performed by calling methods on instances of the :class:`Logger`
 class (hereafter called :dfn:`loggers`). Each instance has a name, and they are
 conceptually arranged in a namespace hierarchy using dots (periods) as
 *format* keyword argument. For all options regarding how a format string is
 constructed, see :ref:`formatter-objects`.
 
+Logging Flow
+^^^^^^^^^^^^
+
+The flow of log event information in loggers and handlers is illustrated in the
+following diagram.
+
+.. image:: logging_flow.png
 
 Loggers
 ^^^^^^^
 libraries, then the logger name specified can be 'orgname.foo' rather than
 just 'foo'.
 
-**PLEASE NOTE:** It is strongly advised that you *do not add any handlers other
-than* :class:`~logging.NullHandler` *to your library's loggers*. This is
-because the configuration of handlers is the prerogative of the application
-developer who uses your library. The application developer knows their target
-audience and what handlers are most appropriate for their application: if you
-add handlers 'under the hood', you might well interfere with their ability to
-carry out unit tests and deliver logs which suit their requirements.
+.. note:: It is strongly advised that you *do not add any handlers other
+   than* :class:`~logging.NullHandler` *to your library's loggers*. This is
+   because the configuration of handlers is the prerogative of the application
+   developer who uses your library. The application developer knows their
+   target audience and what handlers are most appropriate for their
+   application: if you add handlers 'under the hood', you might well interfere
+   with their ability to carry out unit tests and deliver logs which suit their
+   requirements.
 
 
 Logging Levels
 to see if a module-level variable, :data:`raiseExceptions`, is set. If set, a
 traceback is printed to :data:`sys.stderr`. If not set, the exception is swallowed.
 
-**Note:** The default value of :data:`raiseExceptions` is ``True``. This is because
-during development, you typically want to be notified of any exceptions that
-occur. It's advised that you set :data:`raiseExceptions` to ``False`` for production
-usage.
+.. note:: The default value of :data:`raiseExceptions` is ``True``. This is
+   because during development, you typically want to be notified of any
+   exceptions that occur. It's advised that you set :data:`raiseExceptions` to
+   ``False`` for production usage.
 
 .. currentmodule:: logging
 

Doc/howto/logging_flow.png

Added
New image

Doc/howto/regex.rst

 +------------------+-----------------------------------------------+
 
 :meth:`match` and :meth:`search` return ``None`` if no match can be found.  If
-they're successful, a ``MatchObject`` instance is returned, containing
-information about the match: where it starts and ends, the substring it matched,
-and more.
+they're successful, a :ref:`match object <match-objects>` instance is returned,
+containing information about the match: where it starts and ends, the substring
+it matched, and more.
 
 You can learn about this by interactively experimenting with the :mod:`re`
 module.  If you have :mod:`tkinter` available, you may also want to look at
    None
 
 Now, let's try it on a string that it should match, such as ``tempo``.  In this
-case, :meth:`match` will return a :class:`MatchObject`, so you should store the
-result in a variable for later use. ::
+case, :meth:`match` will return a :ref:`match object <match-objects>`, so you
+should store the result in a variable for later use. ::
 
    >>> m = p.match('tempo')
    >>> m  #doctest: +ELLIPSIS
    <_sre.SRE_Match object at 0x...>
 
-Now you can query the :class:`MatchObject` for information about the matching
-string.   :class:`MatchObject` instances also have several methods and
-attributes; the most important ones are:
+Now you can query the :ref:`match object <match-objects>` for information
+about the matching string.  :ref:`match object <match-objects>` instances
+also have several methods and attributes; the most important ones are:
 
 +------------------+--------------------------------------------+
 | Method/Attribute | Purpose                                    |
    >>> m.span()
    (4, 11)
 
-In actual programs, the most common style is to store the :class:`MatchObject`
-in a variable, and then check if it was ``None``.  This usually looks like::
+In actual programs, the most common style is to store the
+:ref:`match object <match-objects>` in a variable, and then check if it was
+``None``.  This usually looks like::
 
    p = re.compile( ... )
    m = p.match( 'string goes here' )
    ['12', '11', '10']
 
 :meth:`findall` has to create the entire list before it can be returned as the
-result.  The :meth:`finditer` method returns a sequence of :class:`MatchObject`
-instances as an :term:`iterator`::
+result.  The :meth:`finditer` method returns a sequence of
+:ref:`match object <match-objects>` instances as an :term:`iterator`::
 
    >>> iterator = p.finditer('12 drummers drumming, 11 ... 10 ...')
    >>> iterator  #doctest: +ELLIPSIS
 :func:`search`, :func:`findall`, :func:`sub`, and so forth.  These functions
 take the same arguments as the corresponding pattern method, with
 the RE string added as the first argument, and still return either ``None`` or a
-:class:`MatchObject` instance. ::
+:ref:`match object <match-objects>` instance. ::
 
    >>> print(re.match(r'From\s+', 'Fromage amk'))
    None
 index of the text that they match; this can be retrieved by passing an argument
 to :meth:`group`, :meth:`start`, :meth:`end`, and :meth:`span`.  Groups are
 numbered starting with 0.  Group 0 is always present; it's the whole RE, so
-:class:`MatchObject` methods all have group 0 as their default argument.  Later
-we'll see how to express groups that don't capture the span of text that they
-match. ::
+:ref:`match object <match-objects>` methods all have group 0 as their default
+argument.  Later we'll see how to express groups that don't capture the span
+of text that they match. ::
 
    >>> p = re.compile('(a)b')
    >>> m = p.match('ab')
 The syntax for a named group is one of the Python-specific extensions:
 ``(?P<name>...)``.  *name* is, obviously, the name of the group.  Named groups
 also behave exactly like capturing groups, and additionally associate a name
-with a group.  The :class:`MatchObject` methods that deal with capturing groups
-all accept either integers that refer to the group by number or strings that
-contain the desired group's name.  Named groups are still given numbers, so you
-can retrieve information about a group in two ways::
+with a group.  The :ref:`match object <match-objects>` methods that deal with
+capturing groups all accept either integers that refer to the group by number
+or strings that contain the desired group's name.  Named groups are still
+given numbers, so you can retrieve information about a group in two ways::
 
    >>> p = re.compile(r'(?P<word>\b\w+\b)')
    >>> m = p.search( '(((( Lots of punctuation )))' )
 
 *replacement* can also be a function, which gives you even more control.  If
 *replacement* is a function, the function is called for every non-overlapping
-occurrence of *pattern*.  On each call, the function is  passed a
-:class:`MatchObject` argument for the match and can use this information to
-compute the desired replacement string and return it.
+occurrence of *pattern*.  On each call, the function is passed a
+:ref:`match object <match-objects>` argument for the match and can use this
+information to compute the desired replacement string and return it.
 
-In the following example, the replacement function translates  decimals into
+In the following example, the replacement function translates decimals into
 hexadecimal::
 
    >>> def hexrepl(match):

Doc/howto/unicode.rst

 machines had different codes, however, which led to problems exchanging files.