[Python-checkins] cpython (merge 2.7 -> 2.7): merge heads
sandro.tosi
python-checkins at python.org
Fri Aug 19 18:47:40 CEST 2011
http://hg.python.org/cpython/rev/d38509db3616
changeset: 71971:d38509db3616
branch: 2.7
parent: 71968:00fe6dd3e0f6
parent: 71965:9f60d180e3c5
user: Sandro Tosi <sandro.tosi at gmail.com>
date: Fri Aug 19 18:43:43 2011 +0200
summary:
merge heads
files:
Doc/distutils/introduction.rst | 4 +-
Doc/distutils/setupscript.rst | 2 +-
Doc/glossary.rst | 102 +-
Doc/howto/cporting.rst | 2 +
Doc/howto/index.rst | 1 +
Doc/howto/pyporting.rst | 703 ++++++++++++++
Doc/install/index.rst | 188 ++-
Doc/library/__future__.rst | 3 +
Doc/library/abc.rst | 4 +
Doc/library/aifc.rst | 4 +
Doc/library/argparse.rst | 110 +-
Doc/library/ast.rst | 14 +-
Doc/library/asynchat.rst | 4 +-
Doc/library/asyncore.rst | 4 +-
Doc/library/atexit.rst | 10 +-
Doc/library/basehttpserver.rst | 4 +
Doc/library/bdb.rst | 4 +
Doc/library/bisect.rst | 13 +-
Doc/library/calendar.rst | 8 +-
Doc/library/cgi.rst | 4 +
Doc/library/cmd.rst | 9 +-
Doc/library/collections.rst | 28 +-
Doc/library/colorsys.rst | 3 +
Doc/library/contextlib.rst | 9 +-
Doc/library/cookie.rst | 3 +
Doc/library/cookielib.rst | 3 +-
Doc/library/dis.rst | 9 +-
Doc/library/dummy_thread.rst | 3 +
Doc/library/dummy_threading.rst | 4 +-
Doc/library/filecmp.rst | 9 +-
Doc/library/fileinput.rst | 8 +-
Doc/library/fnmatch.rst | 10 +-
Doc/library/fractions.rst | 4 +-
Doc/library/ftplib.rst | 4 +
Doc/library/functions.rst | 9 +-
Doc/library/functools.rst | 10 +-
Doc/library/getopt.rst | 5 +-
Doc/library/gettext.rst | 4 +-
Doc/library/glob.rst | 9 +-
Doc/library/gzip.rst | 4 +
Doc/library/hashlib.rst | 5 +-
Doc/library/heapq.rst | 9 +-
Doc/library/hmac.rst | 5 +-
Doc/library/htmllib.rst | 3 +
Doc/library/htmlparser.rst | 4 +
Doc/library/httplib.rst | 4 +
Doc/library/imaplib.rst | 4 +
Doc/library/imghdr.rst | 4 +-
Doc/library/inspect.rst | 5 +-
Doc/library/keyword.rst | 10 +-
Doc/library/linecache.rst | 8 +-
Doc/library/mailcap.rst | 2 +
Doc/library/mimetypes.rst | 4 +
Doc/library/modulefinder.rst | 9 +-
Doc/library/netrc.rst | 4 +
Doc/library/nntplib.rst | 4 +
Doc/library/optparse.rst | 13 +-
Doc/library/pickletools.rst | 4 +
Doc/library/pipes.rst | 4 +-
Doc/library/pkgutil.rst | 9 +-
Doc/library/platform.rst | 4 +
Doc/library/plistlib.rst | 4 +
Doc/library/poplib.rst | 5 +-
Doc/library/pprint.rst | 8 +-
Doc/library/profile.rst | 4 +-
Doc/library/py_compile.rst | 4 +
Doc/library/pyclbr.rst | 4 +-
Doc/library/pydoc.rst | 5 +-
Doc/library/queue.rst | 8 +-
Doc/library/quopri.rst | 10 +-
Doc/library/random.rst | 9 +-
Doc/library/repr.rst | 10 +-
Doc/library/rlcompleter.rst | 4 +-
Doc/library/runpy.rst | 4 +
Doc/library/sched.rst | 9 +-
Doc/library/shelve.rst | 8 +-
Doc/library/shlex.rst | 6 +-
Doc/library/shutil.rst | 12 +-
Doc/library/simplexmlrpcserver.rst | 4 +
Doc/library/site.rst | 134 +-
Doc/library/smtpd.rst | 3 +-
Doc/library/smtplib.rst | 5 +-
Doc/library/sndhdr.rst | 5 +-
Doc/library/socketserver.rst | 4 +-
Doc/library/ssl.rst | 9 +-
Doc/library/stat.rst | 4 +-
Doc/library/stdtypes.rst | 4 +-
Doc/library/string.rst | 10 +-
Doc/library/sunau.rst | 4 +-
Doc/library/symbol.rst | 4 +-
Doc/library/sysconfig.rst | 7 +-
Doc/library/tabnanny.rst | 4 +
Doc/library/tarfile.rst | 5 +-
Doc/library/telnetlib.rst | 5 +-
Doc/library/tempfile.rst | 5 +-
Doc/library/textwrap.rst | 11 +-
Doc/library/threading.rst | 8 +-
Doc/library/timeit.rst | 5 +-
Doc/library/token.rst | 4 +-
Doc/library/tokenize.rst | 9 +-
Doc/library/trace.rst | 9 +-
Doc/library/types.rst | 3 +
Doc/library/urlparse.rst | 8 +-
Doc/library/userdict.rst | 10 +-
Doc/library/uu.rst | 10 +-
Doc/library/warnings.rst | 4 +
Doc/library/wave.rst | 4 +
Doc/library/weakref.rst | 4 +
Doc/library/webbrowser.rst | 4 +-
Doc/library/xdrlib.rst | 5 +-
Doc/library/xml.dom.minidom.rst | 5 +-
Doc/library/xml.dom.pulldom.rst | 5 +-
Doc/library/xml.etree.elementtree.rst | 5 +-
Doc/library/xmlrpclib.rst | 4 +
Doc/library/zipfile.rst | 5 +-
Doc/tools/sphinxext/pyspecific.py | 12 +-
Doc/tutorial/interactive.rst | 7 +-
Doc/tutorial/interpreter.rst | 24 +-
Doc/using/cmdline.rst | 11 +-
Lib/shutil.py | 3 +-
Lib/test/test_shutil.py | 4 +
Makefile.pre.in | 2 +-
Misc/NEWS | 2 +
Tools/scripts/patchcheck.py | 5 +-
124 files changed, 1527 insertions(+), 448 deletions(-)
diff --git a/Doc/distutils/introduction.rst b/Doc/distutils/introduction.rst
--- a/Doc/distutils/introduction.rst
+++ b/Doc/distutils/introduction.rst
@@ -84,8 +84,8 @@
python setup.py sdist
-For Windows, open a command prompt windows ("DOS box") and change the command
-to::
+For Windows, open a command prompt windows (:menuselection:`Start -->
+Accessories`) and change the command to::
setup.py sdist
diff --git a/Doc/distutils/setupscript.rst b/Doc/distutils/setupscript.rst
--- a/Doc/distutils/setupscript.rst
+++ b/Doc/distutils/setupscript.rst
@@ -254,7 +254,7 @@
If you need to include header files from some other Python extension, you can
take advantage of the fact that header files are installed in a consistent way
-by the Distutils :command:`install_header` command. For example, the Numerical
+by the Distutils :command:`install_headers` command. For example, the Numerical
Python header files are installed (on a standard Unix installation) to
:file:`/usr/local/include/python1.5/Numerical`. (The exact location will differ
according to your platform and Python installation.) Since the Python include
diff --git a/Doc/glossary.rst b/Doc/glossary.rst
--- a/Doc/glossary.rst
+++ b/Doc/glossary.rst
@@ -30,7 +30,10 @@
Abstract base classes complement :term:`duck-typing` by
providing a way to define interfaces when other techniques like
:func:`hasattr` would be clumsy or subtly wrong (for example with
- :ref:`magic methods <new-style-special-lookup>`). Python comes with many built-in ABCs for
+ :ref:`magic methods <new-style-special-lookup>`). ABCs introduce virtual
+ subclasses, which are classes that don't inherit from a class but are
+ still recognized by :func:`isinstance` and :func:`issubclass`; see the
+ :mod:`abc` module documentation. Python comes with many built-in ABCs for
data structures (in the :mod:`collections` module), numbers (in the
:mod:`numbers` module), and streams (in the :mod:`io` module). You can
create your own ABCs with the :mod:`abc` module.
@@ -58,11 +61,14 @@
bytecode
Python source code is compiled into bytecode, the internal representation
- of a Python program in the interpreter. The bytecode is also cached in
- ``.pyc`` and ``.pyo`` files so that executing the same file is faster the
- second time (recompilation from source to bytecode can be avoided). This
- "intermediate language" is said to run on a :term:`virtual machine`
- that executes the machine code corresponding to each bytecode.
+ of a Python program in the CPython interpreter. The bytecode is also
+ cached in ``.pyc`` and ``.pyo`` files so that executing the same file is
+ faster the second time (recompilation from source to bytecode can be
+ avoided). This "intermediate language" is said to run on a
+ :term:`virtual machine` that executes the machine code corresponding to
+ each bytecode. Do note that bytecodes are not expected to work between
+ different Python virtual machines, nor to be stable between Python
+ releases.
A list of bytecode instructions can be found in the documentation for
:ref:`the dis module <bytecodes>`.
@@ -128,8 +134,9 @@
def f(...):
...
- See :ref:`the documentation for function definition <function>` for more
- about decorators.
+ The same concept exists for classes, but is less commonly used there. See
+ the documentation for :ref:`function definitions <function>` and
+ :ref:`class definitions <class>` for more about decorators.
descriptor
Any *new-style* object which defines the methods :meth:`__get__`,
@@ -165,8 +172,8 @@
well-designed code improves its flexibility by allowing polymorphic
substitution. Duck-typing avoids tests using :func:`type` or
:func:`isinstance`. (Note, however, that duck-typing can be complemented
- with :term:`abstract base class`\ es.) Instead, it typically employs
- :func:`hasattr` tests or :term:`EAFP` programming.
+ with :term:`abstract base classes <abstract base class>`.) Instead, it
+ typically employs :func:`hasattr` tests or :term:`EAFP` programming.
EAFP
Easier to ask for forgiveness than permission. This common Python coding
@@ -178,17 +185,34 @@
expression
A piece of syntax which can be evaluated to some value. In other words,
- an expression is an accumulation of expression elements like literals, names,
- attribute access, operators or function calls which all return a value.
- In contrast to many other languages, not all language constructs are expressions.
- There are also :term:`statement`\s which cannot be used as expressions,
- such as :keyword:`print` or :keyword:`if`. Assignments are also statements,
- not expressions.
+ an expression is an accumulation of expression elements like literals,
+ names, attribute access, operators or function calls which all return a
+ value. In contrast to many other languages, not all language constructs
+ are expressions. There are also :term:`statement`\s which cannot be used
+ as expressions, such as :keyword:`print` or :keyword:`if`. Assignments
+ are also statements, not expressions.
extension module
A module written in C or C++, using Python's C API to interact with the
core and with user code.
+ file object
+ An object exposing a file-oriented API (with methods such as
+ :meth:`read()` or :meth:`write()`) to an underlying resource. Depending
+ on the way it was created, a file object can mediate access to a real
+ on-disk file or to another other type of storage or communication device
+ (for example standard input/output, in-memory buffers, sockets, pipes,
+ etc.). File objects are also called :dfn:`file-like objects` or
+ :dfn:`streams`.
+
+ There are actually three categories of file objects: raw binary files,
+ buffered binary files and text files. Their interfaces are defined in the
+ :mod:`io` module. The canonical way to create a file object is by using
+ the :func:`open` function.
+
+ file-like object
+ A synonym for :term:`file object`.
+
finder
An object that tries to find the :term:`loader` for a module. It must
implement a method named :meth:`find_module`. See :pep:`302` for
@@ -335,7 +359,7 @@
slowly. See also :term:`interactive`.
iterable
- A container object capable of returning its members one at a
+ 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
@@ -404,6 +428,12 @@
the :term:`EAFP` approach and is characterized by the presence of many
:keyword:`if` statements.
+ In a multi-threaded environment, the LBYL approach can risk introducing a
+ race condition between "the looking" and "the leaping". For example, the
+ code, ``if key in mapping: return mapping[key]`` can fail if another
+ thread removes *key* from *mapping* after the test, but before the lookup.
+ This issue can be solved with locks or by using the EAFP approach.
+
list
A built-in Python :term:`sequence`. Despite its name it is more akin
to an array in other languages than to a linked list since access to
@@ -424,7 +454,8 @@
mapping
A container object that supports arbitrary key lookups and implements the
- methods specified in the :class:`Mapping` or :class:`MutableMapping`
+ methods specified in the :class:`~collections.Mapping` or
+ :class:`~collections.MutableMapping`
:ref:`abstract base classes <collections-abstract-base-classes>`. Examples
include :class:`dict`, :class:`collections.defaultdict`,
:class:`collections.OrderedDict` and :class:`collections.Counter`.
@@ -448,6 +479,14 @@
its first :term:`argument` (which is usually called ``self``).
See :term:`function` and :term:`nested scope`.
+ method resolution order
+ Method Resolution Order is the order in which base classes are searched
+ for a member during lookup. See `The Python 2.3 Method Resolution Order
+ <http://www.python.org/download/releases/2.3/mro/>`_.
+
+ MRO
+ See :term:`method resolution order`.
+
mutable
Mutable objects can change their value but keep their :func:`id`. See
also :term:`immutable`.
@@ -480,10 +519,11 @@
nested scope
The ability to refer to a variable in an enclosing definition. For
instance, a function defined inside another function can refer to
- variables in the outer function. Note that nested scopes work only for
- reference and not for assignment which will always write to the innermost
- scope. In contrast, local variables both read and write in the innermost
- scope. Likewise, global variables read and write to the global namespace.
+ variables in the outer function. Note that nested scopes by default work
+ only for reference and not for assignment. Local variables both read and
+ write in the innermost scope. Likewise, global variables read and write
+ to the global namespace. The :keyword:`nonlocal` allows writing to outer
+ scopes.
new-style class
Any class which inherits from :class:`object`. This includes all built-in
@@ -506,9 +546,9 @@
:term:`argument`.
Python 3000
- Nickname for the next major Python version, 3.0 (coined long ago
- when the release of version 3 was something in the distant future.) This
- is also abbreviated "Py3k".
+ Nickname for the Python 3.x release line (coined long ago when the release
+ of version 3 was something in the distant future.) This is also
+ abbreviated "Py3k".
Pythonic
An idea or piece of code which closely follows the most common idioms
@@ -531,7 +571,7 @@
object drops to zero, it is deallocated. Reference counting is
generally not visible to Python code, but it is a key element of the
:term:`CPython` implementation. The :mod:`sys` module defines a
- :func:`getrefcount` function that programmers can call to return the
+ :func:`~sys.getrefcount` function that programmers can call to return the
reference count for a particular object.
__slots__
@@ -567,7 +607,15 @@
statement
A statement is part of a suite (a "block" of code). A statement is either
an :term:`expression` or a one of several constructs with a keyword, such
- as :keyword:`if`, :keyword:`while` or :keyword:`print`.
+ as :keyword:`if`, :keyword:`while` or :keyword:`for`.
+
+ struct sequence
+ A tuple with named elements. Struct sequences expose an interface similiar
+ to :term:`named tuple` in that elements can either be accessed either by
+ index or as an attribute. However, they do not have any of the named tuple
+ methods like :meth:`~collections.somenamedtuple._make` or
+ :meth:`~collections.somenamedtuple._asdict`. Examples of struct sequences
+ include :data:`sys.float_info` and the return value of :func:`os.stat`.
triple-quoted string
A string which is bound by three instances of either a quotation mark
diff --git a/Doc/howto/cporting.rst b/Doc/howto/cporting.rst
--- a/Doc/howto/cporting.rst
+++ b/Doc/howto/cporting.rst
@@ -1,5 +1,7 @@
.. highlightlang:: c
+.. _cporting-howto:
+
********************************
Porting Extension Modules to 3.0
********************************
diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
--- a/Doc/howto/index.rst
+++ b/Doc/howto/index.rst
@@ -14,6 +14,7 @@
:maxdepth: 1
advocacy.rst
+ pyporting.rst
cporting.rst
curses.rst
descriptor.rst
diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst
new file mode 100644
--- /dev/null
+++ b/Doc/howto/pyporting.rst
@@ -0,0 +1,703 @@
+.. _pyporting-howto:
+
+*********************************
+Porting Python 2 Code to Python 3
+*********************************
+
+:author: Brett Cannon
+
+.. topic:: Abstract
+
+ With Python 3 being the future of Python while Python 2 is still in active
+ use, it is good to have your project available for both major releases of
+ Python. This guide is meant to help you choose which strategy works best
+ for your project to support both Python 2 & 3 along with how to execute
+ that strategy.
+
+ If you are looking to port an extension module instead of pure Python code,
+ please see :ref:`cporting-howto`.
+
+
+Choosing a Strategy
+===================
+
+When a project makes the decision that it's time to support both Python 2 & 3,
+a decision needs to be made as to how to go about accomplishing that goal.
+The chosen strategy will depend on how large the project's existing
+codebase is and how much divergence you want from your Python 2 codebase from
+your Python 3 one (e.g., starting a new version with Python 3).
+
+If your project is brand-new or does not have a large codebase, then you may
+want to consider writing/porting :ref:`all of your code for Python 3
+and use 3to2 <use_3to2>` to port your code for Python 2.
+
+If you would prefer to maintain a codebase which is semantically **and**
+syntactically compatible with Python 2 & 3 simultaneously, you can write
+:ref:`use_same_source`. While this tends to lead to somewhat non-idiomatic
+code, it does mean you keep a rapid development process for you, the developer.
+
+Finally, you do have the option of :ref:`using 2to3 <use_2to3>` to translate
+Python 2 code into Python 3 code (with some manual help). This can take the
+form of branching your code and using 2to3 to start a Python 3 branch. You can
+also have users perform the translation as installation time automatically so
+that you only have to maintain a Python 2 codebase.
+
+Regardless of which approach you choose, porting is not as hard or
+time-consuming as you might initially think. You can also tackle the problem
+piece-meal as a good portion of porting is simply updating your code to follow
+current best practices in a Python 2/3 compatible way.
+
+
+Universal Bits of Advice
+------------------------
+
+Regardless of what strategy you pick, there are a few things you should
+consider.
+
+One is make sure you have a robust test suite. You need to make sure everything
+continues to work, just like when you support a new minor version of Python.
+This means making sure your test suite is thorough and is ported properly
+between Python 2 & 3. You will also most likely want to use something like tox_
+to automate testing between both a Python 2 and Python 3 VM.
+
+Two, once your project has Python 3 support, make sure to add the proper
+classifier on the Cheeseshop_ (PyPI_). To have your project listed as Python 3
+compatible it must have the
+`Python 3 classifier <http://pypi.python.org/pypi?:action=browse&c=533>`_
+(from
+http://techspot.zzzeek.org/2011/01/24/zzzeek-s-guide-to-python-3-porting/)::
+
+ setup(
+ name='Your Library',
+ version='1.0',
+ classifiers=[
+ # make sure to use :: Python *and* :: Python :: 3 so
+ # that pypi can list the package on the python 3 page
+ 'Programming Language :: Python',
+ 'Programming Language :: Python :: 3'
+ ],
+ packages=['yourlibrary'],
+ # make sure to add custom_fixers to the MANIFEST.in
+ include_package_data=True,
+ # ...
+ )
+
+
+Doing so will cause your project to show up in the
+`Python 3 packages list
+<http://pypi.python.org/pypi?:action=browse&c=533&show=all>`_. You will know
+you set the classifier properly as visiting your project page on the Cheeseshop
+will show a Python 3 logo in the upper-left corner of the page.
+
+Three, the six_ project provides a library which helps iron out differences
+between Python 2 & 3. If you find there is a sticky point that is a continual
+point of contention in your translation or maintenance of code, consider using
+a source-compatible solution relying on six. If you have to create your own
+Python 2/3 compatible solution, you can use ``sys.version_info[0] >= 3`` as a
+guard.
+
+Four, read all the approaches. Just because some bit of advice applies to one
+approach more than another doesn't mean that some advice doesn't apply to other
+strategies.
+
+Five, drop support for older Python versions if possible. `Python 2.5`_
+introduced a lot of useful syntax and libraries which have become idiomatic
+in Python 3. `Python 2.6`_ introduced future statements which makes
+compatibility much easier if you are going from Python 2 to 3.
+`Python 2.7`_ continues the trend in the stdlib. So choose the newest version
+of Python which you believe can be your minimum support version
+and work from there.
+
+
+.. _tox: http://codespeak.net/tox/
+.. _Cheeseshop:
+.. _PyPI: http://pypi.python.org/
+.. _six: http://packages.python.org/six
+.. _Python 2.7: http://www.python.org/2.7.x
+.. _Python 2.6: http://www.python.org/2.6.x
+.. _Python 2.5: http://www.python.org/2.5.x
+.. _Python 2.4: http://www.python.org/2.4.x
+.. _Python 2.3: http://www.python.org/2.3.x
+.. _Python 2.2: http://www.python.org/2.2.x
+
+
+.. _use_3to2:
+
+Python 3 and 3to2
+=================
+
+If you are starting a new project or your codebase is small enough, you may
+want to consider writing your code for Python 3 and backporting to Python 2
+using 3to2_. Thanks to Python 3 being more strict about things than Python 2
+(e.g., bytes vs. strings), the source translation can be easier and more
+straightforward than from Python 2 to 3. Plus it gives you more direct
+experience developing in Python 3 which, since it is the future of Python, is a
+good thing long-term.
+
+A drawback of this approach is that 3to2 is a third-party project. This means
+that the Python core developers (and thus this guide) can make no promises
+about how well 3to2 works at any time. There is nothing to suggest, though,
+that 3to2 is not a high-quality project.
+
+
+.. _3to2: https://bitbucket.org/amentajo/lib3to2/overview
+
+
+.. _use_2to3:
+
+Python 2 and 2to3
+=================
+
+Included with Python since 2.6, the 2to3_ tool (and :mod:`lib2to3` module)
+helps with porting Python 2 to Python 3 by performing various source
+translations. This is a perfect solution for projects which wish to branch
+their Python 3 code from their Python 2 codebase and maintain them as
+independent codebases. You can even begin preparing to use this approach
+today by writing future-compatible Python code which works cleanly in
+Python 2 in conjunction with 2to3; all steps outlined below will work
+with Python 2 code up to the point when the actual use of 2to3 occurs.
+
+Use of 2to3 as an on-demand translation step at install time is also possible,
+preventing the need to maintain a separate Python 3 codebase, but this approach
+does come with some drawbacks. While users will only have to pay the
+translation cost once at installation, you as a developer will need to pay the
+cost regularly during development. If your codebase is sufficiently large
+enough then the translation step ends up acting like a compilation step,
+robbing you of the rapid development process you are used to with Python.
+Obviously the time required to translate a project will vary, so do an
+experimental translation just to see how long it takes to evaluate whether you
+prefer this approach compared to using :ref:`use_same_source` or simply keeping
+a separate Python 3 codebase.
+
+Below are the typical steps taken by a project which uses a 2to3-based approach
+to supporting Python 2 & 3.
+
+
+Support Python 2.7
+------------------
+
+As a first step, make sure that your project is compatible with `Python 2.7`_.
+This is just good to do as Python 2.7 is the last release of Python 2 and thus
+will be used for a rather long time. It also allows for use of the ``-3`` flag
+to Python to help discover places in your code which 2to3 cannot handle but are
+known to cause issues.
+
+Try to Support `Python 2.6`_ and Newer Only
+-------------------------------------------
+
+While not possible for all projects, if you can support `Python 2.6`_ and newer
+**only**, your life will be much easier. Various future statements, stdlib
+additions, etc. exist only in Python 2.6 and later which greatly assist in
+porting to Python 3. But if you project must keep support for `Python 2.5`_ (or
+even `Python 2.4`_) then it is still possible to port to Python 3.
+
+Below are the benefits you gain if you only have to support Python 2.6 and
+newer. Some of these options are personal choice while others are
+**strongly** recommended (the ones that are more for personal choice are
+labeled as such). If you continue to support older versions of Python then you
+at least need to watch out for situations that these solutions fix.
+
+
+``from __future__ import print_function``
+'''''''''''''''''''''''''''''''''''''''''
+
+This is a personal choice. 2to3 handles the translation from the print
+statement to the print function rather well so this is an optional step. This
+future statement does help, though, with getting used to typing
+``print('Hello, World')`` instead of ``print 'Hello, World'``.
+
+
+``from __future__ import unicode_literals``
+'''''''''''''''''''''''''''''''''''''''''''
+
+Another personal choice. You can always mark what you want to be a (unicode)
+string with a ``u`` prefix to get the same effect. But regardless of whether
+you use this future statement or not, you **must** make sure you know exactly
+which Python 2 strings you want to be bytes, and which are to be strings. This
+means you should, **at minimum** mark all strings that are meant to be text
+strings with a ``u`` prefix if you do not use this future statement.
+
+
+Bytes literals
+''''''''''''''
+
+This is a **very** important one. The ability to prefix Python 2 strings that
+are meant to contain bytes with a ``b`` prefix help to very clearly delineate
+what is and is not a Python 3 string. When you run 2to3 on code, all Python 2
+strings become Python 3 strings **unless** they are prefixed with ``b``.
+
+There are some differences between byte literals in Python 2 and those in
+Python 3 thanks to the bytes type just being an alias to ``str`` in Python 2.
+Probably the biggest "gotcha" is that indexing results in different values. In
+Python 2, the value of ``b'py'[1]`` is ``'y'``, while in Python 3 it's ``121``.
+You can avoid this disparity by always slicing at the size of a single element:
+``b'py'[1:2]`` is ``'y'`` in Python 2 and ``b'y'`` in Python 3 (i.e., close
+enough).
+
+You cannot concatenate bytes and strings in Python 3. But since in Python
+2 has bytes aliased to ``str``, it will succeed: ``b'a' + u'b'`` works in
+Python 2, but ``b'a' + 'b'`` in Python 3 is a :exc:`TypeError`. A similar issue
+also comes about when doing comparisons between bytes and strings.
+
+
+Supporting `Python 2.5`_ and Newer Only
+---------------------------------------
+
+If you are supporting `Python 2.5`_ and newer there are still some features of
+Python that you can utilize.
+
+
+``from __future__ import absolute_import``
+''''''''''''''''''''''''''''''''''''''''''
+
+Implicit relative imports (e.g., importing ``spam.bacon`` from within
+``spam.eggs`` with the statement ``import bacon``) does not work in Python 3.
+This future statement moves away from that and allows the use of explicit
+relative imports (e.g., ``from . import bacon``).
+
+In `Python 2.5`_ you must use
+the __future__ statement to get to use explicit relative imports and prevent
+implicit ones. In `Python 2.6`_ explicit relative imports are available without
+the statement, but you still want the __future__ statement to prevent implicit
+relative imports. In `Python 2.7`_ the __future__ statement is not needed. In
+other words, unless you are only supporting Python 2.7 or a version earlier
+than Python 2.5, use the __future__ statement.
+
+
+
+Handle Common "Gotchas"
+-----------------------
+
+There are a few things that just consistently come up as sticking points for
+people which 2to3 cannot handle automatically or can easily be done in Python 2
+to help modernize your code.
+
+
+``from __future__ import division``
+'''''''''''''''''''''''''''''''''''
+
+While the exact same outcome can be had by using the ``-Qnew`` argument to
+Python, using this future statement lifts the requirement that your users use
+the flag to get the expected behavior of division in Python 3
+(e.g., ``1/2 == 0.5; 1//2 == 0``).
+
+
+
+Specify when opening a file as binary
+'''''''''''''''''''''''''''''''''''''
+
+Unless you have been working on Windows, there is a chance you have not always
+bothered to add the ``b`` mode when opening a binary file (e.g., ``rb`` for
+binary reading). Under Python 3, binary files and text files are clearly
+distinct and mutually incompatible; see the :mod:`io` module for details.
+Therefore, you **must** make a decision of whether a file will be used for
+binary access (allowing to read and/or write bytes data) or text access
+(allowing to read and/or write unicode data).
+
+Text files
+''''''''''
+
+Text files created using ``open()`` under Python 2 return byte strings,
+while under Python 3 they return unicode strings. Depending on your porting
+strategy, this can be an issue.
+
+If you want text files to return unicode strings in Python 2, you have two
+possibilities:
+
+* Under Python 2.6 and higher, use :func:`io.open`. Since :func:`io.open`
+ is essentially the same function in both Python 2 and Python 3, it will
+ help iron out any issues that might arise.
+
+* If pre-2.6 compatibility is needed, then you should use :func:`codecs.open`
+ instead. This will make sure that you get back unicode strings in Python 2.
+
+Subclass ``object``
+'''''''''''''''''''
+
+New-style classes have been around since `Python 2.2`_. You need to make sure
+you are subclassing from ``object`` to avoid odd edge cases involving method
+resolution order, etc. This continues to be totally valid in Python 3 (although
+unneeded as all classes implicitly inherit from ``object``).
+
+
+Deal With the Bytes/String Dichotomy
+''''''''''''''''''''''''''''''''''''
+
+One of the biggest issues people have when porting code to Python 3 is handling
+the bytes/string dichotomy. Because Python 2 allowed the ``str`` type to hold
+textual data, people have over the years been rather loose in their delineation
+of what ``str`` instances held text compared to bytes. In Python 3 you cannot
+be so care-free anymore and need to properly handle the difference. The key
+handling this issue to to make sure that **every** string literal in your
+Python 2 code is either syntactically of functionally marked as either bytes or
+text data. After this is done you then need to make sure your APIs are designed
+to either handle a specific type or made to be properly polymorphic.
+
+
+Mark Up Python 2 String Literals
+********************************
+
+First thing you must do is designate every single string literal in Python 2
+as either textual or bytes data. If you are only supporting Python 2.6 or
+newer, this can be accomplished by marking bytes literals with a ``b`` prefix
+and then designating textual data with a ``u`` prefix or using the
+``unicode_literals`` future statement.
+
+If your project supports versions of Python pre-dating 2.6, then you should use
+the six_ project and its ``b()`` function to denote bytes literals. For text
+literals you can either use six's ``u()`` function or use a ``u`` prefix.
+
+
+Decide what APIs Will Accept
+****************************
+
+In Python 2 it was very easy to accidentally create an API that accepted both
+bytes and textual data. But in Python 3, thanks to the more strict handling of
+disparate types, this loose usage of bytes and text together tends to fail.
+
+Take the dict ``{b'a': 'bytes', u'a': 'text'}`` in Python 2.6. It creates the
+dict ``{u'a': 'text'}`` since ``b'a' == u'a'``. But in Python 3 the equivalent
+dict creates ``{b'a': 'bytes', 'a': 'text'}``, i.e., no lost data. Similar
+issues can crop up when transitioning Python 2 code to Python 3.
+
+This means you need to choose what an API is going to accept and create and
+consistently stick to that API in both Python 2 and 3.
+
+
+Bytes / Unicode Comparison
+**************************
+
+In Python 3, mixing bytes and unicode is forbidden in most situations; it
+will raise a :class:`TypeError` where Python 2 would have attempted an implicit
+coercion between types. However, there is one case where it doesn't and
+it can be very misleading::
+
+ >>> b"" == ""
+ False
+
+This is because an equality comparison is required by the language to always
+succeed (and return ``False`` for incompatible types). However, this also
+means that code incorrectly ported to Python 3 can display buggy behaviour
+if such comparisons are silently executed. To detect such situations,
+Python 3 has a ``-b`` flag that will display a warning::
+
+ $ python3 -b
+ >>> b"" == ""
+ __main__:1: BytesWarning: Comparison between bytes and string
+ False
+
+To turn the warning into an exception, use the ``-bb`` flag instead::
+
+ $ python3 -bb
+ >>> b"" == ""
+ Traceback (most recent call last):
+ File "<stdin>", line 1, in <module>
+ BytesWarning: Comparison between bytes and string
+
+
+Indexing bytes objects
+''''''''''''''''''''''
+
+Another potentially surprising change is the indexing behaviour of bytes
+objects in Python 3::
+
+ >>> b"xyz"[0]
+ 120
+
+Indeed, Python 3 bytes objects (as well as :class:`bytearray` objects)
+are sequences of integers. But code converted from Python 2 will often
+assume that indexing a bytestring produces another bytestring, not an
+integer. To reconcile both behaviours, use slicing::
+
+ >>> b"xyz"[0:1]
+ b'x'
+ >>> n = 1
+ >>> b"xyz"[n:n+1]
+ b'y'
+
+The only remaining gotcha is that an out-of-bounds slice returns an empty
+bytes object instead of raising ``IndexError``:
+
+ >>> b"xyz"[3]
+ Traceback (most recent call last):
+ File "<stdin>", line 1, in <module>
+ IndexError: index out of range
+ >>> b"xyz"[3:4]
+ b''
+
+
+``__str__()``/``__unicode__()``
+'''''''''''''''''''''''''''''''
+
+In Python 2, objects can specify both a string and unicode representation of
+themselves. In Python 3, though, there is only a string representation. This
+becomes an issue as people can inadvertently do things in their ``__str__()``
+methods which have unpredictable results (e.g., infinite recursion if you
+happen to use the ``unicode(self).encode('utf8')`` idiom as the body of your
+``__str__()`` method).
+
+There are two ways to solve this issue. One is to use a custom 2to3 fixer. The
+blog post at http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/
+specifies how to do this. That will allow 2to3 to change all instances of ``def
+__unicode(self): ...`` to ``def __str__(self): ...``. This does require you
+define your ``__str__()`` method in Python 2 before your ``__unicode__()``
+method.
+
+The other option is to use a mixin class. This allows you to only define a
+``__unicode__()`` method for your class and let the mixin derive
+``__str__()`` for you (code from
+http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/)::
+
+ import sys
+
+ class UnicodeMixin(object):
+
+ """Mixin class to handle defining the proper __str__/__unicode__
+ methods in Python 2 or 3."""
+
+ if sys.version_info[0] >= 3: # Python 3
+ def __str__(self):
+ return self.__unicode__()
+ else: # Python 2
+ def __str__(self):
+ return self.__unicode__().encode('utf8')
+
+
+ class Spam(UnicodeMixin):
+
+ def __unicode__(self):
+ return u'spam-spam-bacon-spam' # 2to3 will remove the 'u' prefix
+
+
+Don't Index on Exceptions
+'''''''''''''''''''''''''
+
+In Python 2, the following worked::
+
+ >>> exc = Exception(1, 2, 3)
+ >>> exc.args[1]
+ 2
+ >>> exc[1] # Python 2 only!
+ 2
+
+But in Python 3, indexing directly on an exception is an error. You need to
+make sure to only index on the :attr:`BaseException.args` attribute which is a
+sequence containing all arguments passed to the :meth:`__init__` method.
+
+Even better is to use the documented attributes the exception provides.
+
+Don't use ``__getslice__`` & Friends
+''''''''''''''''''''''''''''''''''''
+
+Been deprecated for a while, but Python 3 finally drops support for
+``__getslice__()``, etc. Move completely over to :meth:`__getitem__` and
+friends.
+
+
+Updating doctests
+'''''''''''''''''
+
+2to3_ will attempt to generate fixes for doctests that it comes across. It's
+not perfect, though. If you wrote a monolithic set of doctests (e.g., a single
+docstring containing all of your doctests), you should at least consider
+breaking the doctests up into smaller pieces to make it more manageable to fix.
+Otherwise it might very well be worth your time and effort to port your tests
+to :mod:`unittest`.
+
+
+Eliminate ``-3`` Warnings
+-------------------------
+
+When you run your application's test suite, run it using the ``-3`` flag passed
+to Python. This will cause various warnings to be raised during execution about
+things that 2to3 cannot handle automatically (e.g., modules that have been
+removed). Try to eliminate those warnings to make your code even more portable
+to Python 3.
+
+
+Run 2to3
+--------
+
+Once you have made your Python 2 code future-compatible with Python 3, it's
+time to use 2to3_ to actually port your code.
+
+
+Manually
+''''''''
+
+To manually convert source code using 2to3_, you use the ``2to3`` script that
+is installed with Python 2.6 and later.::
+
+ 2to3 <directory or file to convert>
+
+This will cause 2to3 to write out a diff with all of the fixers applied for the
+converted source code. If you would like 2to3 to go ahead and apply the changes
+you can pass it the ``-w`` flag::
+
+ 2to3 -w <stuff to convert>
+
+There are other flags available to control exactly which fixers are applied,
+etc.
+
+
+During Installation
+'''''''''''''''''''
+
+When a user installs your project for Python 3, you can have either
+:mod:`distutils` or Distribute_ run 2to3_ on your behalf.
+For distutils, use the following idiom::
+
+ try: # Python 3
+ from distutils.command.build_py import build_py_2to3 as build_py
+ except ImportError: # Python 2
+ from distutils.command.build_py import build_py
+
+ setup(cmdclass = {'build_py': build_py},
+ # ...
+ )
+
+For Distribute::
+
+ setup(use_2to3=True,
+ # ...
+ )
+
+This will allow you to not have to distribute a separate Python 3 version of
+your project. It does require, though, that when you perform development that
+you at least build your project and use the built Python 3 source for testing.
+
+
+Verify & Test
+-------------
+
+At this point you should (hopefully) have your project converted in such a way
+that it works in Python 3. Verify it by running your unit tests and making sure
+nothing has gone awry. If you miss something then figure out how to fix it in
+Python 3, backport to your Python 2 code, and run your code through 2to3 again
+to verify the fix transforms properly.
+
+
+.. _2to3: http://docs.python.org/py3k/library/2to3.html
+.. _Distribute: http://packages.python.org/distribute/
+
+
+.. _use_same_source:
+
+Python 2/3 Compatible Source
+============================
+
+While it may seem counter-intuitive, you can write Python code which is
+source-compatible between Python 2 & 3. It does lead to code that is not
+entirely idiomatic Python (e.g., having to extract the currently raised
+exception from ``sys.exc_info()[1]``), but it can be run under Python 2
+**and** Python 3 without using 2to3_ as a translation step (although the tool
+should be used to help find potential portability problems). This allows you to
+continue to have a rapid development process regardless of whether you are
+developing under Python 2 or Python 3. Whether this approach or using
+:ref:`use_2to3` works best for you will be a per-project decision.
+
+To get a complete idea of what issues you will need to deal with, see the
+`What's New in Python 3.0`_. Others have reorganized the data in other formats
+such as http://docs.pythonsprints.com/python3_porting/py-porting.html .
+
+The following are some steps to take to try to support both Python 2 & 3 from
+the same source code.
+
+
+.. _What's New in Python 3.0: http://docs.python.org/release/3.0/whatsnew/3.0.html
+
+
+Follow The Steps for Using 2to3_
+--------------------------------
+
+All of the steps outlined in how to
+:ref:`port Python 2 code with 2to3 <use_2to3>` apply
+to creating a Python 2/3 codebase. This includes trying only support Python 2.6
+or newer (the :mod:`__future__` statements work in Python 3 without issue),
+eliminating warnings that are triggered by ``-3``, etc.
+
+You should even consider running 2to3_ over your code (without committing the
+changes). This will let you know where potential pain points are within your
+code so that you can fix them properly before they become an issue.
+
+
+Use six_
+--------
+
+The six_ project contains many things to help you write portable Python code.
+You should make sure to read its documentation from beginning to end and use
+any and all features it provides. That way you will minimize any mistakes you
+might make in writing cross-version code.
+
+
+Capturing the Currently Raised Exception
+----------------------------------------
+
+One change between Python 2 and 3 that will require changing how you code (if
+you support `Python 2.5`_ and earlier) is
+accessing the currently raised exception. In Python 2.5 and earlier the syntax
+to access the current exception is::
+
+ try:
+ raise Exception()
+ except Exception, exc:
+ # Current exception is 'exc'
+ pass
+
+This syntax changed in Python 3 (and backported to `Python 2.6`_ and later)
+to::
+
+ try:
+ raise Exception()
+ except Exception as exc:
+ # Current exception is 'exc'
+ # In Python 3, 'exc' is restricted to the block; Python 2.6 will "leak"
+ pass
+
+Because of this syntax change you must change to capturing the current
+exception to::
+
+ try:
+ raise Exception()
+ except Exception:
+ import sys
+ exc = sys.exc_info()[1]
+ # Current exception is 'exc'
+ pass
+
+You can get more information about the raised exception from
+:func:`sys.exc_info` than simply the current exception instance, but you most
+likely don't need it.
+
+.. note::
+ In Python 3, the traceback is attached to the exception instance
+ through the ``__traceback__`` attribute. If the instance is saved in
+ a local variable that persists outside of the ``except`` block, the
+ traceback will create a reference cycle with the current frame and its
+ dictionary of local variables. This will delay reclaiming dead
+ resources until the next cyclic :term:`garbage collection` pass.
+
+ In Python 2, this problem only occurs if you save the traceback itself
+ (e.g. the third element of the tuple returned by :func:`sys.exc_info`)
+ in a variable.
+
+
+Other Resources
+===============
+
+The authors of the following blog posts, wiki pages, and books deserve special
+thanks for making public their tips for porting Python 2 code to Python 3 (and
+thus helping provide information for this document):
+
+* http://python3porting.com/
+* http://docs.pythonsprints.com/python3_porting/py-porting.html
+* http://techspot.zzzeek.org/2011/01/24/zzzeek-s-guide-to-python-3-porting/
+* http://dabeaz.blogspot.com/2011/01/porting-py65-and-my-superboard-to.html
+* http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/
+* http://lucumr.pocoo.org/2010/2/11/porting-to-python-3-a-guide/
+* http://wiki.python.org/moin/PortingPythonToPy3k
+
+If you feel there is something missing from this document that should be added,
+please email the python-porting_ mailing list.
+
+.. _python-porting: http://mail.python.org/mailman/listinfo/python-porting
diff --git a/Doc/install/index.rst b/Doc/install/index.rst
--- a/Doc/install/index.rst
+++ b/Doc/install/index.rst
@@ -101,8 +101,8 @@
python setup.py install
-For Windows, this command should be run from a command prompt windows ("DOS
-box")::
+For Windows, this command should be run from a command prompt window
+(:menuselection:`Start --> Accessories`)::
setup.py install
@@ -144,7 +144,7 @@
:file:`C:\\Temp\\foo-1.0`; you can use either a archive manipulator with a
graphical user interface (such as WinZip) or a command-line tool (such as
:program:`unzip` or :program:`pkunzip`) to unpack the archive. Then, open a
-command prompt window ("DOS box"), and run::
+command prompt window and run::
cd c:\Temp\foo-1.0
python setup.py install
@@ -279,6 +279,12 @@
>>> sys.exec_prefix
'/usr'
+A few other placeholders are used in this document: :file:`{X.Y}` stands for the
+version of Python, for example ``2.7``; :file:`{distname}` will be replaced by
+the name of the module distribution being installed. Dots and capitalization
+are important in the paths; for example, a value that uses ``python2.7`` on UNIX
+will typically use ``Python27`` on Windows.
+
If you don't want to install modules to the standard location, or if you don't
have permission to write there, then you need to read about alternate
installations in section :ref:`inst-alt-install`. If you want to customize your
@@ -307,8 +313,61 @@
differ across platforms, so read whichever of the following sections applies to
you.
+Note that the various alternate installation schemes are mutually exclusive: you
+can pass ``--user``, or ``--home``, or ``--prefix`` and ``--exec-prefix``, or
+``--install-base`` and ``--install-platbase``, but you can't mix from these
+groups.
-.. _inst-alt-install-prefix:
+
+.. _inst-alt-install-user:
+
+Alternate installation: the user scheme
+---------------------------------------
+
+This scheme is designed to be the most convenient solution for users that don't
+have write permission to the global site-packages directory or don't want to
+install into it. It is enabled with a simple option::
+
+ python setup.py install --user
+
+Files will be installed into subdirectories of :data:`site.USER_BASE` (written
+as :file:`{userbase}` hereafter). This scheme installs pure Python modules and
+extension modules in the same location (also known as :data:`site.USER_SITE`).
+Here are the values for UNIX, including Mac OS X:
+
+=============== ===========================================================
+Type of file Installation directory
+=============== ===========================================================
+modules :file:`{userbase}/lib/python{X.Y}/site-packages`
+scripts :file:`{userbase}/bin`
+data :file:`{userbase}`
+C headers :file:`{userbase}/include/python{X.Y}/{distname}`
+=============== ===========================================================
+
+And here are the values used on Windows:
+
+=============== ===========================================================
+Type of file Installation directory
+=============== ===========================================================
+modules :file:`{userbase}\\Python{XY}\\site-packages`
+scripts :file:`{userbase}\\Scripts`
+data :file:`{userbase}`
+C headers :file:`{userbase}\\Python{XY}\\Include\\{distname}`
+=============== ===========================================================
+
+The advantage of using this scheme compared to the other ones described below is
+that the user site-packages directory is under normal conditions always included
+in :data:`sys.path` (see :mod:`site` for more information), which means that
+there is no additional step to perform after running the :file:`setup.py` script
+to finalize the installation.
+
+The :command:`build_ext` command also has a ``--user`` option to add
+:file:`{userbase}/include` to the compiler search path for header files and
+:file:`{userbase}/lib` to the compiler search path for libraries as well as to
+the runtime search path for shared C libraries (rpath).
+
+
+.. _inst-alt-install-home:
Alternate installation: the home scheme
---------------------------------------
@@ -330,26 +389,30 @@
python setup.py install --home=~
+To make Python find the distributions installed with this scheme, you may have
+to :ref:`modify Python's search path <inst-search-path>` or edit
+:mod:`sitecustomize` (see :mod:`site`) to call :func:`site.addsitedir` or edit
+:data:`sys.path`.
+
The :option:`--home` option defines the installation base directory. Files are
installed to the following directories under the installation base as follows:
-+------------------------------+---------------------------+-----------------------------+
-| Type of file | Installation Directory | Override option |
-+==============================+===========================+=============================+
-| pure module distribution | :file:`{home}/lib/python` | :option:`--install-purelib` |
-+------------------------------+---------------------------+-----------------------------+
-| non-pure module distribution | :file:`{home}/lib/python` | :option:`--install-platlib` |
-+------------------------------+---------------------------+-----------------------------+
-| scripts | :file:`{home}/bin` | :option:`--install-scripts` |
-+------------------------------+---------------------------+-----------------------------+
-| data | :file:`{home}/share` | :option:`--install-data` |
-+------------------------------+---------------------------+-----------------------------+
+=============== ===========================================================
+Type of file Installation directory
+=============== ===========================================================
+modules :file:`{home}/lib/python`
+scripts :file:`{home}/bin`
+data :file:`{home}`
+C headers :file:`{home}/include/python/{distname}`
+=============== ===========================================================
+
+(Mentally replace slashes with backslashes if you're on Windows.)
.. versionchanged:: 2.4
The :option:`--home` option used to be supported only on Unix.
-.. _inst-alt-install-home:
+.. _inst-alt-install-prefix-unix:
Alternate installation: Unix (the prefix scheme)
------------------------------------------------
@@ -358,7 +421,7 @@
perform the build/install (i.e., to run the setup script), but install modules
into the third-party module directory of a different Python installation (or
something that looks like a different Python installation). If this sounds a
-trifle unusual, it is---that's why the "home scheme" comes first. However,
+trifle unusual, it is---that's why the user and home schemes come before. However,
there are at least two known cases where the prefix scheme will be useful.
First, consider that many Linux distributions put Python in :file:`/usr`, rather
@@ -386,17 +449,15 @@
executables, etc.) If :option:`--exec-prefix` is not supplied, it defaults to
:option:`--prefix`. Files are installed as follows:
-+------------------------------+-----------------------------------------------------+-----------------------------+
-| Type of file | Installation Directory | Override option |
-+==============================+=====================================================+=============================+
-| pure module distribution | :file:`{prefix}/lib/python{X.Y}/site-packages` | :option:`--install-purelib` |
-+------------------------------+-----------------------------------------------------+-----------------------------+
-| non-pure module distribution | :file:`{exec-prefix}/lib/python{X.Y}/site-packages` | :option:`--install-platlib` |
-+------------------------------+-----------------------------------------------------+-----------------------------+
-| scripts | :file:`{prefix}/bin` | :option:`--install-scripts` |
-+------------------------------+-----------------------------------------------------+-----------------------------+
-| data | :file:`{prefix}/share` | :option:`--install-data` |
-+------------------------------+-----------------------------------------------------+-----------------------------+
+================= ==========================================================
+Type of file Installation directory
+================= ==========================================================
+Python modules :file:`{prefix}/lib/python{X.Y}/site-packages`
+extension modules :file:`{exec-prefix}/lib/python{X.Y}/site-packages`
+scripts :file:`{prefix}/bin`
+data :file:`{prefix}`
+C headers :file:`{prefix}/include/python{X.Y}/{distname}`
+================= ==========================================================
There is no requirement that :option:`--prefix` or :option:`--exec-prefix`
actually point to an alternate Python installation; if the directories listed
@@ -421,7 +482,7 @@
alternate Python installation, this is immaterial.)
-.. _inst-alt-install-windows:
+.. _inst-alt-install-prefix-windows:
Alternate installation: Windows (the prefix scheme)
---------------------------------------------------
@@ -436,20 +497,18 @@
to install modules to the :file:`\\Temp\\Python` directory on the current drive.
The installation base is defined by the :option:`--prefix` option; the
-:option:`--exec-prefix` option is not supported under Windows. Files are
-installed as follows:
+:option:`--exec-prefix` option is not supported under Windows, which means that
+pure Python modules and extension modules are installed into the same location.
+Files are installed as follows:
-+------------------------------+---------------------------+-----------------------------+
-| Type of file | Installation Directory | Override option |
-+==============================+===========================+=============================+
-| pure module distribution | :file:`{prefix}` | :option:`--install-purelib` |
-+------------------------------+---------------------------+-----------------------------+
-| non-pure module distribution | :file:`{prefix}` | :option:`--install-platlib` |
-+------------------------------+---------------------------+-----------------------------+
-| scripts | :file:`{prefix}\\Scripts` | :option:`--install-scripts` |
-+------------------------------+---------------------------+-----------------------------+
-| data | :file:`{prefix}\\Data` | :option:`--install-data` |
-+------------------------------+---------------------------+-----------------------------+
+=============== ==========================================================
+Type of file Installation directory
+=============== ==========================================================
+modules :file:`{prefix}\\Lib\\site-packages`
+scripts :file:`{prefix}\\Scripts`
+data :file:`{prefix}`
+C headers :file:`{prefix}\\Include\\{distname}`
+=============== ==========================================================
.. _inst-custom-install:
@@ -463,13 +522,29 @@
or you might want to completely redefine the installation scheme. In either
case, you're creating a *custom installation scheme*.
-You probably noticed the column of "override options" in the tables describing
-the alternate installation schemes above. Those options are how you define a
-custom installation scheme. These override options can be relative, absolute,
+To create a custom installation scheme, you start with one of the alternate
+schemes and override some of the installation directories used for the various
+types of files, using these options:
+
+====================== =======================
+Type of file Override option
+====================== =======================
+Python modules ``--install-purelib``
+extension modules ``--install-platlib``
+all modules ``--install-lib``
+scripts ``--install-scripts``
+data ``--install-data``
+C headers ``--install-headers``
+====================== =======================
+
+These override options can be relative, absolute,
or explicitly defined in terms of one of the installation base directories.
(There are two installation base directories, and they are normally the same---
they only differ when you use the Unix "prefix scheme" and supply different
-:option:`--prefix` and :option:`--exec-prefix` options.)
+``--prefix`` and ``--exec-prefix`` options; using ``--install-lib`` will
+override values computed or given for ``--install-purelib`` and
+``--install-platlib``, and is recommended for schemes that don't make a
+difference between Python and extension modules.)
For example, say you're installing a module distribution to your home directory
under Unix---but you want scripts to go in :file:`~/scripts` rather than
@@ -496,15 +571,16 @@
a subdirectory of :file:`{prefix}`, rather than right in :file:`{prefix}`
itself. This is almost as easy as customizing the script installation directory
---you just have to remember that there are two types of modules to worry about,
-pure modules and non-pure modules (i.e., modules from a non-pure distribution).
-For example::
+Python and extension modules, which can conveniently be both controlled by one
+option::
- python setup.py install --install-purelib=Site --install-platlib=Site
+ python setup.py install --install-lib=Site
-The specified installation directories are relative to :file:`{prefix}`. Of
-course, you also have to ensure that these directories are in Python's module
-search path, such as by putting a :file:`.pth` file in :file:`{prefix}`. See
-section :ref:`inst-search-path` to find out how to modify Python's search path.
+The specified installation directory is relative to :file:`{prefix}`. Of
+course, you also have to ensure that this directory is in Python's module
+search path, such as by putting a :file:`.pth` file in a site directory (see
+:mod:`site`). See section :ref:`inst-search-path` to find out how to modify
+Python's search path.
If you want to define an entire installation scheme, you just have to supply all
of the installation directory options. The recommended way to do this is to
@@ -556,8 +632,8 @@
python setup.py install --install-base=/tmp
-would install pure modules to :file:`{/tmp/python/lib}` in the first case, and
-to :file:`{/tmp/lib}` in the second case. (For the second case, you probably
+would install pure modules to :file:`/tmp/python/lib` in the first case, and
+to :file:`/tmp/lib` in the second case. (For the second case, you probably
want to supply an installation base of :file:`/tmp/python`.)
You probably noticed the use of ``$HOME`` and ``$PLAT`` in the sample
@@ -574,7 +650,7 @@
needed on those platforms?
-.. XXX I'm not sure where this section should go.
+.. XXX Move this to Doc/using
.. _inst-search-path:
diff --git a/Doc/library/__future__.rst b/Doc/library/__future__.rst
--- a/Doc/library/__future__.rst
+++ b/Doc/library/__future__.rst
@@ -4,6 +4,9 @@
.. module:: __future__
:synopsis: Future statement definitions
+**Source code:** :source:`Lib/__future__.py`
+
+--------------
:mod:`__future__` is a real module, and serves three purposes:
diff --git a/Doc/library/abc.rst b/Doc/library/abc.rst
--- a/Doc/library/abc.rst
+++ b/Doc/library/abc.rst
@@ -9,6 +9,10 @@
.. versionadded:: 2.6
+**Source code:** :source:`Lib/abc.py`
+
+--------------
+
This module provides the infrastructure for defining :term:`abstract base
classes <abstract base class>` (ABCs) in Python, as outlined in :pep:`3119`; see the PEP for why this
was added to Python. (See also :pep:`3141` and the :mod:`numbers` module
diff --git a/Doc/library/aifc.rst b/Doc/library/aifc.rst
--- a/Doc/library/aifc.rst
+++ b/Doc/library/aifc.rst
@@ -10,6 +10,10 @@
single: AIFF
single: AIFF-C
+**Source code:** :source:`Lib/aifc.py`
+
+--------------
+
This module provides support for reading and writing AIFF and AIFF-C files.
AIFF is Audio Interchange File Format, a format for storing digital audio
samples in a file. AIFF-C is a newer version of the format that includes the
diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -2,11 +2,15 @@
===============================================================================
.. module:: argparse
- :synopsis: Command-line option and argument-parsing library.
+ :synopsis: Command-line option and argument parsing library.
.. moduleauthor:: Steven Bethard <steven.bethard at gmail.com>
-.. versionadded:: 2.7
.. sectionauthor:: Steven Bethard <steven.bethard at gmail.com>
+.. versionadded:: 2.7
+
+**Source code:** :source:`Lib/argparse.py`
+
+--------------
The :mod:`argparse` module makes it easy to write user-friendly command-line
interfaces. The program defines what arguments it requires, and :mod:`argparse`
@@ -103,9 +107,9 @@
Parsing arguments
^^^^^^^^^^^^^^^^^
-:class:`ArgumentParser` parses args through the
+:class:`ArgumentParser` parses arguments through the
:meth:`~ArgumentParser.parse_args` method. This will inspect the command line,
-convert each arg to the appropriate type and then invoke the appropriate action.
+convert each argument to the appropriate type and then invoke the appropriate action.
In most cases, this means a simple :class:`Namespace` object will be built up from
attributes parsed out of the command line::
@@ -114,7 +118,7 @@
In a script, :meth:`~ArgumentParser.parse_args` will typically be called with no
arguments, and the :class:`ArgumentParser` will automatically determine the
-command-line args from :data:`sys.argv`.
+command-line arguments from :data:`sys.argv`.
ArgumentParser objects
@@ -238,7 +242,7 @@
--foo FOO foo help
The help option is typically ``-h/--help``. The exception to this is
-if the ``prefix_chars=`` is specified and does not include ``'-'``, in
+if the ``prefix_chars=`` is specified and does not include ``-``, in
which case ``-h`` and ``--help`` are not valid options. In
this case, the first character in ``prefix_chars`` is used to prefix
the help options::
@@ -254,7 +258,7 @@
prefix_chars
^^^^^^^^^^^^
-Most command-line options will use ``'-'`` as the prefix, e.g. ``-f/--foo``.
+Most command-line options will use ``-`` as the prefix, e.g. ``-f/--foo``.
Parsers that need to support different or additional prefix
characters, e.g. for options
like ``+f`` or ``/foo``, may specify them using the ``prefix_chars=`` argument
@@ -267,7 +271,7 @@
Namespace(bar='Y', f='X')
The ``prefix_chars=`` argument defaults to ``'-'``. Supplying a set of
-characters that does not include ``'-'`` will cause ``-f/--foo`` options to be
+characters that does not include ``-`` will cause ``-f/--foo`` options to be
disallowed.
@@ -389,7 +393,7 @@
likewise for this epilog whose whitespace will be cleaned up and whose words
will be wrapped across a couple lines
-Passing :class:`~argparse.RawDescriptionHelpFormatter` as ``formatter_class=``
+Passing :class:`RawDescriptionHelpFormatter` as ``formatter_class=``
indicates that description_ and epilog_ are already correctly formatted and
should not be line-wrapped::
@@ -415,7 +419,7 @@
optional arguments:
-h, --help show this help message and exit
-:class:`RawTextHelpFormatter` maintains whitespace for all sorts of help text
+:class:`RawTextHelpFormatter` maintains whitespace for all sorts of help text,
including argument descriptions.
The other formatter class available, :class:`ArgumentDefaultsHelpFormatter`,
@@ -642,11 +646,11 @@
action
^^^^^^
-:class:`ArgumentParser` objects associate command-line args with actions. These
-actions can do just about anything with the command-line args associated with
+:class:`ArgumentParser` objects associate command-line arguments with actions. These
+actions can do just about anything with the command-line arguments associated with
them, though most actions simply add an attribute to the object returned by
:meth:`~ArgumentParser.parse_args`. The ``action`` keyword argument specifies
-how the command-line args should be handled. The supported actions are:
+how the command-line arguments should be handled. The supported actions are:
* ``'store'`` - This just stores the argument's value. This is the default
action. For example::
@@ -718,8 +722,8 @@
:meth:`~ArgumentParser.parse_args`. Most actions add an attribute to this
object.
-* ``values`` - The associated command-line args, with any type-conversions
- applied. (Type-conversions are specified with the type_ keyword argument to
+* ``values`` - The associated command-line arguments, with any type conversions
+ applied. (Type conversions are specified with the type_ keyword argument to
:meth:`~ArgumentParser.add_argument`.
* ``option_string`` - The option string that was used to invoke this action.
@@ -751,7 +755,7 @@
different number of command-line arguments with a single action. The supported
values are:
-* N (an integer). N args from the command line will be gathered together into a
+* ``N`` (an integer). ``N`` arguments from the command line will be gathered together into a
list. For example::
>>> parser = argparse.ArgumentParser()
@@ -763,11 +767,11 @@
Note that ``nargs=1`` produces a list of one item. This is different from
the default, in which the item is produced by itself.
-* ``'?'``. One arg will be consumed from the command line if possible, and
- produced as a single item. If no command-line arg is present, the value from
+* ``'?'``. One argument will be consumed from the command line if possible, and
+ produced as a single item. If no command-line argument is present, the value from
default_ will be produced. Note that for optional arguments, there is an
additional case - the option string is present but not followed by a
- command-line arg. In this case the value from const_ will be produced. Some
+ command-line argument. In this case the value from const_ will be produced. Some
examples to illustrate this::
>>> parser = argparse.ArgumentParser()
@@ -795,7 +799,7 @@
Namespace(infile=<open file '<stdin>', mode 'r' at 0x...>,
outfile=<open file '<stdout>', mode 'w' at 0x...>)
-* ``'*'``. All command-line args present are gathered into a list. Note that
+* ``'*'``. All command-line arguments present are gathered into a list. Note that
it generally doesn't make much sense to have more than one positional argument
with ``nargs='*'``, but multiple optional arguments with ``nargs='*'`` is
possible. For example::
@@ -809,7 +813,7 @@
* ``'+'``. Just like ``'*'``, all command-line args present are gathered into a
list. Additionally, an error message will be generated if there wasn't at
- least one command-line arg present. For example::
+ least one command-line argument present. For example::
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('foo', nargs='+')
@@ -819,8 +823,8 @@
usage: PROG [-h] foo [foo ...]
PROG: error: too few arguments
-If the ``nargs`` keyword argument is not provided, the number of args consumed
-is determined by the action_. Generally this means a single command-line arg
+If the ``nargs`` keyword argument is not provided, the number of arguments consumed
+is determined by the action_. Generally this means a single command-line argument
will be consumed and a single item (not a list) will be produced.
@@ -837,9 +841,9 @@
* When :meth:`~ArgumentParser.add_argument` is called with option strings
(like ``-f`` or ``--foo``) and ``nargs='?'``. This creates an optional
- argument that can be followed by zero or one command-line args.
+ argument that can be followed by zero or one command-line arguments.
When parsing the command line, if the option string is encountered with no
- command-line arg following it, the value of ``const`` will be assumed instead.
+ command-line argument following it, the value of ``const`` will be assumed instead.
See the nargs_ description for examples.
The ``const`` keyword argument defaults to ``None``.
@@ -851,7 +855,7 @@
All optional arguments and some positional arguments may be omitted at the
command line. The ``default`` keyword argument of
:meth:`~ArgumentParser.add_argument`, whose value defaults to ``None``,
-specifies what value should be used if the command-line arg is not present.
+specifies what value should be used if the command-line argument is not present.
For optional arguments, the ``default`` value is used when the option string
was not present at the command line::
@@ -862,8 +866,8 @@
>>> parser.parse_args(''.split())
Namespace(foo=42)
-For positional arguments with nargs_ ``='?'`` or ``'*'``, the ``default`` value
-is used when no command-line arg was present::
+For positional arguments with nargs_ equal to ``?`` or ``*``, the ``default`` value
+is used when no command-line argument was present::
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', nargs='?', default=42)
@@ -887,12 +891,12 @@
type
^^^^
-By default, ArgumentParser objects read command-line args in as simple strings.
-However, quite often the command-line string should instead be interpreted as
-another type, like a :class:`float`, :class:`int` or :class:`file`. The
+By default, :class:`ArgumentParser` objects read command-line arguments in as simple
+strings. However, quite often the command-line string should instead be
+interpreted as another type, like a :class:`float` or :class:`int`. The
``type`` keyword argument of :meth:`~ArgumentParser.add_argument` allows any
-necessary type-checking and type-conversions to be performed. Many common
-built-in types can be used directly as the value of the ``type`` argument::
+necessary type-checking and type conversions to be performed. Common built-in
+types and functions can be used directly as the value of the ``type`` argument::
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', type=int)
@@ -911,7 +915,7 @@
Namespace(bar=<open file 'out.txt', mode 'w' at 0x...>)
``type=`` can take any callable that takes a single string argument and returns
-the type-converted value::
+the converted value::
>>> def perfect_square(string):
... value = int(string)
@@ -946,11 +950,11 @@
choices
^^^^^^^
-Some command-line args should be selected from a restricted set of values.
+Some command-line arguments should be selected from a restricted set of values.
These can be handled by passing a container object as the ``choices`` keyword
argument to :meth:`~ArgumentParser.add_argument`. When the command line is
-parsed, arg values will be checked, and an error message will be displayed if
-the arg was not one of the acceptable values::
+parsed, argument values will be checked, and an error message will be displayed if
+the argument was not one of the acceptable values::
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('foo', choices='abc')
@@ -1053,7 +1057,7 @@
actions, the dest_ value is used directly, and for optional argument actions,
the dest_ value is uppercased. So, a single positional argument with
``dest='bar'`` will that argument will be referred to as ``bar``. A single
-optional argument ``--foo`` that should be followed by a single command-line arg
+optional argument ``--foo`` that should be followed by a single command-line argument
will be referred to as ``FOO``. An example::
>>> parser = argparse.ArgumentParser()
@@ -1125,10 +1129,10 @@
For optional argument actions, the value of ``dest`` is normally inferred from
the option strings. :class:`ArgumentParser` generates the value of ``dest`` by
-taking the first long option string and stripping away the initial ``'--'``
+taking the first long option string and stripping away the initial ``--``
string. If no long option strings were supplied, ``dest`` will be derived from
-the first short option string by stripping the initial ``'-'`` character. Any
-internal ``'-'`` characters will be converted to ``'_'`` characters to make sure
+the first short option string by stripping the initial ``-`` character. Any
+internal ``-`` characters will be converted to ``_`` characters to make sure
the string is a valid attribute name. The examples below illustrate this
behavior::
@@ -1160,7 +1164,7 @@
created and how they are assigned. See the documentation for
:meth:`add_argument` for details.
- By default, the arg strings are taken from :data:`sys.argv`, and a new empty
+ By default, the argument strings are taken from :data:`sys.argv`, and a new empty
:class:`Namespace` object is created for the attributes.
@@ -1231,15 +1235,15 @@
PROG: error: extra arguments found: badger
-Arguments containing ``"-"``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Arguments containing ``-``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
The :meth:`~ArgumentParser.parse_args` method attempts to give errors whenever
the user has clearly made a mistake, but some situations are inherently
-ambiguous. For example, the command-line arg ``'-1'`` could either be an
+ambiguous. For example, the command-line argument ``-1`` could either be an
attempt to specify an option or an attempt to provide a positional argument.
The :meth:`~ArgumentParser.parse_args` method is cautious here: positional
-arguments may only begin with ``'-'`` if they look like negative numbers and
+arguments may only begin with ``-`` if they look like negative numbers and
there are no options in the parser that look like negative numbers::
>>> parser = argparse.ArgumentParser(prog='PROG')
@@ -1272,7 +1276,7 @@
usage: PROG [-h] [-1 ONE] [foo]
PROG: error: argument -1: expected one argument
-If you have positional arguments that must begin with ``'-'`` and don't look
+If you have positional arguments that must begin with ``-`` and don't look
like negative numbers, you can insert the pseudo-argument ``'--'`` which tells
:meth:`~ArgumentParser.parse_args` that everything after that is a positional
argument::
@@ -1304,7 +1308,7 @@
Beyond ``sys.argv``
^^^^^^^^^^^^^^^^^^^
-Sometimes it may be useful to have an ArgumentParser parse args other than those
+Sometimes it may be useful to have an ArgumentParser parse arguments other than those
of :data:`sys.argv`. This can be accomplished by passing a list of strings to
:meth:`~ArgumentParser.parse_args`. This is useful for testing at the
interactive prompt::
@@ -1390,7 +1394,7 @@
>>> parser_b = subparsers.add_parser('b', help='b help')
>>> parser_b.add_argument('--baz', choices='XYZ', help='baz help')
>>>
- >>> # parse some arg lists
+ >>> # parse some argument lists
>>> parser.parse_args(['a', '12'])
Namespace(bar=12, foo=False)
>>> parser.parse_args(['--foo', 'b', '--baz', 'Z'])
@@ -1399,8 +1403,8 @@
Note that the object returned by :meth:`parse_args` will only contain
attributes for the main parser and the subparser that was selected by the
command line (and not any other subparsers). So in the example above, when
- the ``"a"`` command is specified, only the ``foo`` and ``bar`` attributes are
- present, and when the ``"b"`` command is specified, only the ``foo`` and
+ the ``a`` command is specified, only the ``foo`` and ``bar`` attributes are
+ present, and when the ``b`` command is specified, only the ``foo`` and
``baz`` attributes are present.
Similarly, when a help message is requested from a subparser, only the help
@@ -1522,7 +1526,7 @@
The :class:`FileType` factory creates objects that can be passed to the type
argument of :meth:`ArgumentParser.add_argument`. Arguments that have
- :class:`FileType` objects as their type will open command-line args as files
+ :class:`FileType` objects as their type will open command-line arguments as files
with the requested modes and buffer sizes:
>>> parser = argparse.ArgumentParser()
@@ -1636,7 +1640,7 @@
.. method:: ArgumentParser.set_defaults(**kwargs)
Most of the time, the attributes of the object returned by :meth:`parse_args`
- will be fully determined by inspecting the command-line args and the argument
+ will be fully determined by inspecting the command-line arguments and the argument
actions. :meth:`set_defaults` allows some additional
attributes that are determined without any inspection of the command line to
be added::
diff --git a/Doc/library/ast.rst b/Doc/library/ast.rst
--- a/Doc/library/ast.rst
+++ b/Doc/library/ast.rst
@@ -1,7 +1,5 @@
-.. _ast:
-
-Abstract Syntax Trees
-=====================
+:mod:`ast` --- Abstract Syntax Trees
+====================================
.. module:: ast
:synopsis: Abstract Syntax Tree classes and manipulation.
@@ -15,6 +13,9 @@
.. versionadded:: 2.6
The high-level ``ast`` module containing all helpers.
+**Source code:** :source:`Lib/ast.py`
+
+--------------
The :mod:`ast` module helps Python applications to process trees of the Python
abstract syntax grammar. The abstract syntax itself might change with each
@@ -28,11 +29,6 @@
compiled into a Python code object using the built-in :func:`compile` function.
-.. seealso::
-
- Latest version of the `ast module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/ast.py?view=markup>`_
-
Node classes
------------
diff --git a/Doc/library/asynchat.rst b/Doc/library/asynchat.rst
--- a/Doc/library/asynchat.rst
+++ b/Doc/library/asynchat.rst
@@ -1,4 +1,3 @@
-
:mod:`asynchat` --- Asynchronous socket command/response handler
================================================================
@@ -7,6 +6,9 @@
.. moduleauthor:: Sam Rushing <rushing at nightmare.com>
.. sectionauthor:: Steve Holden <sholden at holdenweb.com>
+**Source code:** :source:`Lib/asynchat.py`
+
+--------------
This module builds on the :mod:`asyncore` infrastructure, simplifying
asynchronous clients and servers and making it easier to handle protocols
diff --git a/Doc/library/asyncore.rst b/Doc/library/asyncore.rst
--- a/Doc/library/asyncore.rst
+++ b/Doc/library/asyncore.rst
@@ -1,4 +1,3 @@
-
:mod:`asyncore` --- Asynchronous socket handler
===============================================
@@ -10,6 +9,9 @@
.. sectionauthor:: Steve Holden <sholden at holdenweb.com>
.. heavily adapted from original documentation by Sam Rushing
+**Source code:** :source:`Lib/asyncore.py`
+
+--------------
This module provides the basic infrastructure for writing asynchronous socket
service clients and servers.
diff --git a/Doc/library/atexit.rst b/Doc/library/atexit.rst
--- a/Doc/library/atexit.rst
+++ b/Doc/library/atexit.rst
@@ -1,4 +1,3 @@
-
:mod:`atexit` --- Exit handlers
===============================
@@ -10,17 +9,16 @@
.. versionadded:: 2.0
+**Source code:** :source:`Lib/atexit.py`
+
+--------------
+
The :mod:`atexit` module defines a single function to register cleanup
functions. Functions thus registered are automatically executed upon normal
interpreter termination. The order in which the functions are called is not
defined; if you have cleanup operations that depend on each other, you should
wrap them in a function and register that one. This keeps :mod:`atexit` simple.
-.. seealso::
-
- Latest version of the `atexit Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/atexit.py?view=markup>`_
-
Note: the functions registered via this module are not called when the program
is killed by a signal not handled by Python, when a Python fatal internal error
is detected, or when :func:`os._exit` is called.
diff --git a/Doc/library/basehttpserver.rst b/Doc/library/basehttpserver.rst
--- a/Doc/library/basehttpserver.rst
+++ b/Doc/library/basehttpserver.rst
@@ -18,6 +18,10 @@
module: SimpleHTTPServer
module: CGIHTTPServer
+**Source code:** :source:`Lib/BaseHTTPServer.py`
+
+--------------
+
This module defines two classes for implementing HTTP servers (Web servers).
Usually, this module isn't used directly, but is used as a basis for building
functioning Web servers. See the :mod:`SimpleHTTPServer` and
diff --git a/Doc/library/bdb.rst b/Doc/library/bdb.rst
--- a/Doc/library/bdb.rst
+++ b/Doc/library/bdb.rst
@@ -4,6 +4,10 @@
.. module:: bdb
:synopsis: Debugger framework.
+**Source code:** :source:`Lib/bdb.py`
+
+--------------
+
The :mod:`bdb` module handles basic debugger functions, like setting breakpoints
or managing execution via the debugger.
diff --git a/Doc/library/bisect.rst b/Doc/library/bisect.rst
--- a/Doc/library/bisect.rst
+++ b/Doc/library/bisect.rst
@@ -7,6 +7,12 @@
.. sectionauthor:: Raymond Hettinger <python at rcn.com>
.. example based on the PyModules FAQ entry by Aaron Watters <arw at pythonpros.com>
+.. versionadded:: 2.1
+
+**Source code:** :source:`Lib/bisect.py`
+
+--------------
+
This module provides support for maintaining a list in sorted order without
having to sort the list after each insertion. For long lists of items with
expensive comparison operations, this can be an improvement over the more common
@@ -14,13 +20,6 @@
algorithm to do its work. The source code may be most useful as a working
example of the algorithm (the boundary conditions are already right!).
-.. versionadded:: 2.1
-
-.. seealso::
-
- Latest version of the `bisect module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/bisect.py?view=markup>`_
-
The following functions are provided:
diff --git a/Doc/library/calendar.rst b/Doc/library/calendar.rst
--- a/Doc/library/calendar.rst
+++ b/Doc/library/calendar.rst
@@ -1,4 +1,3 @@
-
:mod:`calendar` --- General calendar-related functions
======================================================
@@ -7,6 +6,9 @@
program.
.. sectionauthor:: Drew Csillag <drew_csillag at geocities.com>
+**Source code:** :source:`Lib/calendar.py`
+
+--------------
This module allows you to output calendars like the Unix :program:`cal` program,
and provides additional useful functions related to the calendar. By default,
@@ -22,10 +24,6 @@
calendar in Dershowitz and Reingold's book "Calendrical Calculations", where
it's the base calendar for all computations.
-.. seealso::
-
- Latest version of the `calendar module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/calendar.py?view=markup>`_
.. class:: Calendar([firstweekday])
diff --git a/Doc/library/cgi.rst b/Doc/library/cgi.rst
--- a/Doc/library/cgi.rst
+++ b/Doc/library/cgi.rst
@@ -13,6 +13,10 @@
single: URL
single: Common Gateway Interface
+**Source code:** :source:`Lib/cgi.py`
+
+--------------
+
Support module for Common Gateway Interface (CGI) scripts.
This module defines a number of utilities for use by CGI scripts written in
diff --git a/Doc/library/cmd.rst b/Doc/library/cmd.rst
--- a/Doc/library/cmd.rst
+++ b/Doc/library/cmd.rst
@@ -1,4 +1,3 @@
-
:mod:`cmd` --- Support for line-oriented command interpreters
=============================================================
@@ -6,17 +5,15 @@
:synopsis: Build line-oriented command interpreters.
.. sectionauthor:: Eric S. Raymond <esr at snark.thyrsus.com>
+**Source code:** :source:`Lib/cmd.py`
+
+--------------
The :class:`Cmd` class provides a simple framework for writing line-oriented
command interpreters. These are often useful for test harnesses, administrative
tools, and prototypes that will later be wrapped in a more sophisticated
interface.
-.. seealso::
-
- Latest version of the `cmd module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/cmd.py?view=markup>`_
-
.. class:: Cmd([completekey[, stdin[, stdout]]])
A :class:`Cmd` instance or subclass instance is a line-oriented interpreter
diff --git a/Doc/library/collections.rst b/Doc/library/collections.rst
--- a/Doc/library/collections.rst
+++ b/Doc/library/collections.rst
@@ -1,4 +1,3 @@
-
:mod:`collections` --- High-performance container datatypes
===========================================================
@@ -15,6 +14,10 @@
import itertools
__name__ = '<doctest>'
+**Source code:** :source:`Lib/collections.py` and :source:`Lib/_abcoll.py`
+
+--------------
+
This module implements specialized container datatypes providing alternatives to
Python's general purpose built-in containers, :class:`dict`, :class:`list`,
:class:`set`, and :class:`tuple`.
@@ -28,13 +31,10 @@
===================== ==================================================================== ===========================
In addition to the concrete container classes, the collections module provides
-:ref:`collections-abstract-base-classes` that can be used to test whether a class provides a
-particular interface, for example, whether it is hashable or a mapping.
+:ref:`abstract base classes <collections-abstract-base-classes>` that can be
+used to test whether a class provides a particular interface, for example,
+whether it is hashable or a mapping.
-.. seealso::
-
- Latest version of the `collections module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/collections.py?view=markup>`_
:class:`Counter` objects
------------------------
@@ -202,14 +202,14 @@
* `Bag class <http://www.gnu.org/software/smalltalk/manual-base/html_node/Bag.html>`_
in Smalltalk.
- * Wikipedia entry for `Multisets <http://en.wikipedia.org/wiki/Multiset>`_\.
+ * Wikipedia entry for `Multisets <http://en.wikipedia.org/wiki/Multiset>`_.
* `C++ multisets <http://www.demo2s.com/Tutorial/Cpp/0380__set-multiset/Catalog0380__set-multiset.htm>`_
tutorial with examples.
* For mathematical operations on multisets and their use cases, see
*Knuth, Donald. The Art of Computer Programming Volume II,
- Section 4.6.3, Exercise 19*\.
+ Section 4.6.3, Exercise 19*.
* To enumerate all distinct multisets of a given size over a given set of
elements, see :func:`itertools.combinations_with_replacement`.
@@ -453,8 +453,7 @@
:class:`defaultdict` objects support the following method in addition to the
standard :class:`dict` operations:
-
- .. method:: defaultdict.__missing__(key)
+ .. method:: __missing__(key)
If the :attr:`default_factory` attribute is ``None``, this raises a
:exc:`KeyError` exception with the *key* as argument.
@@ -474,7 +473,7 @@
:class:`defaultdict` objects support the following instance variable:
- .. attribute:: defaultdict.default_factory
+ .. attribute:: default_factory
This attribute is used by the :meth:`__missing__` method; it is
initialized from the first argument to the constructor, if present, or to
@@ -858,7 +857,7 @@
del self[key]
OrderedDict.__setitem__(self, key, value)
-An ordered dictionary can combined with the :class:`Counter` class
+An ordered dictionary can be combined with the :class:`Counter` class
so that the counter remembers the order elements are first encountered::
class OrderedCounter(Counter, OrderedDict):
@@ -1023,9 +1022,6 @@
.. seealso::
- * Latest version of the `Python source code for the collections abstract base classes
- <http://svn.python.org/view/python/branches/release27-maint/Lib/_abcoll.py?view=markup>`_
-
* `OrderedSet recipe <http://code.activestate.com/recipes/576694/>`_ for an
example built on :class:`MutableSet`.
diff --git a/Doc/library/colorsys.rst b/Doc/library/colorsys.rst
--- a/Doc/library/colorsys.rst
+++ b/Doc/library/colorsys.rst
@@ -5,6 +5,9 @@
:synopsis: Conversion functions between RGB and other color systems.
.. sectionauthor:: David Ascher <da at python.net>
+**Source code:** :source:`Lib/colorsys.py`
+
+--------------
The :mod:`colorsys` module defines bidirectional conversions of color values
between colors expressed in the RGB (Red Green Blue) color space used in
diff --git a/Doc/library/contextlib.rst b/Doc/library/contextlib.rst
--- a/Doc/library/contextlib.rst
+++ b/Doc/library/contextlib.rst
@@ -7,15 +7,14 @@
.. versionadded:: 2.5
+**Source code:** :source:`Lib/contextlib.py`
+
+--------------
+
This module provides utilities for common tasks involving the :keyword:`with`
statement. For more information see also :ref:`typecontextmanager` and
:ref:`context-managers`.
-.. seealso::
-
- Latest version of the `contextlib Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/contextlib.py?view=markup>`_
-
Functions provided:
diff --git a/Doc/library/cookie.rst b/Doc/library/cookie.rst
--- a/Doc/library/cookie.rst
+++ b/Doc/library/cookie.rst
@@ -11,6 +11,9 @@
3.0. The :term:`2to3` tool will automatically adapt imports when converting
your sources to 3.0.
+**Source code:** :source:`Lib/Cookie.py`
+
+--------------
The :mod:`Cookie` module defines classes for abstracting the concept of
cookies, an HTTP state management mechanism. It supports both simple string-only
diff --git a/Doc/library/cookielib.rst b/Doc/library/cookielib.rst
--- a/Doc/library/cookielib.rst
+++ b/Doc/library/cookielib.rst
@@ -11,10 +11,11 @@
Python 3.0. The :term:`2to3` tool will automatically adapt imports when
converting your sources to 3.0.
-
.. versionadded:: 2.4
+**Source code:** :source:`Lib/cookielib.py`
+--------------
The :mod:`cookielib` module defines classes for automatic handling of HTTP
cookies. It is useful for accessing web sites that require small pieces of data
diff --git a/Doc/library/dis.rst b/Doc/library/dis.rst
--- a/Doc/library/dis.rst
+++ b/Doc/library/dis.rst
@@ -1,21 +1,18 @@
-
:mod:`dis` --- Disassembler for Python bytecode
===============================================
.. module:: dis
:synopsis: Disassembler for Python bytecode.
+**Source code:** :source:`Lib/dis.py`
+
+--------------
The :mod:`dis` module supports the analysis of CPython :term:`bytecode` by
disassembling it. The CPython bytecode which this module takes as an
input is defined in the file :file:`Include/opcode.h` and used by the compiler
and the interpreter.
-.. seealso::
-
- Latest version of the `dis module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/dis.py?view=markup>`_
-
.. impl-detail::
Bytecode is an implementation detail of the CPython interpreter! No
diff --git a/Doc/library/dummy_thread.rst b/Doc/library/dummy_thread.rst
--- a/Doc/library/dummy_thread.rst
+++ b/Doc/library/dummy_thread.rst
@@ -10,6 +10,9 @@
converting your sources to 3.0; however, you should consider using the
high-lever :mod:`dummy_threading` module instead.
+**Source code:** :source:`Lib/dummy_thread.py`
+
+--------------
This module provides a duplicate interface to the :mod:`thread` module. It is
meant to be imported when the :mod:`thread` module is not provided on a
diff --git a/Doc/library/dummy_threading.rst b/Doc/library/dummy_threading.rst
--- a/Doc/library/dummy_threading.rst
+++ b/Doc/library/dummy_threading.rst
@@ -1,10 +1,12 @@
-
:mod:`dummy_threading` --- Drop-in replacement for the :mod:`threading` module
==============================================================================
.. module:: dummy_threading
:synopsis: Drop-in replacement for the threading module.
+**Source code:** :source:`Lib/dummy_threading.py`
+
+--------------
This module provides a duplicate interface to the :mod:`threading` module. It
is meant to be imported when the :mod:`thread` module is not provided on a
diff --git a/Doc/library/filecmp.rst b/Doc/library/filecmp.rst
--- a/Doc/library/filecmp.rst
+++ b/Doc/library/filecmp.rst
@@ -1,4 +1,3 @@
-
:mod:`filecmp` --- File and Directory Comparisons
=================================================
@@ -6,16 +5,14 @@
:synopsis: Compare files efficiently.
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
+**Source code:** :source:`Lib/filecmp.py`
+
+--------------
The :mod:`filecmp` module defines functions to compare files and directories,
with various optional time/correctness trade-offs. For comparing files,
see also the :mod:`difflib` module.
-.. seealso::
-
- Latest version of the `filecmp Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/filecmp.py?view=markup>`_
-
The :mod:`filecmp` module defines the following functions:
diff --git a/Doc/library/fileinput.rst b/Doc/library/fileinput.rst
--- a/Doc/library/fileinput.rst
+++ b/Doc/library/fileinput.rst
@@ -6,6 +6,9 @@
.. moduleauthor:: Guido van Rossum <guido at python.org>
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/fileinput.py`
+
+--------------
This module implements a helper class and functions to quickly write a
loop over standard input or a list of files. If you just want to read or
@@ -44,11 +47,6 @@
returns an accordingly opened file-like object. Two useful hooks are already
provided by this module.
-.. seealso::
-
- Latest version of the `fileinput Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/fileinput.py?view=markup>`_
-
The following function is the primary interface of this module:
diff --git a/Doc/library/fnmatch.rst b/Doc/library/fnmatch.rst
--- a/Doc/library/fnmatch.rst
+++ b/Doc/library/fnmatch.rst
@@ -1,4 +1,3 @@
-
:mod:`fnmatch` --- Unix filename pattern matching
=================================================
@@ -10,6 +9,10 @@
.. index:: module: re
+**Source code:** :source:`Lib/fnmatch.py`
+
+--------------
+
This module provides support for Unix shell-style wildcards, which are *not* the
same as regular expressions (which are documented in the :mod:`re` module). The
special characters used in shell-style wildcards are:
@@ -34,10 +37,6 @@
a period are not special for this module, and are matched by the ``*`` and ``?``
patterns.
-.. seealso::
-
- Latest version of the `fnmatch Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/fnmatch.py?view=markup>`_
.. function:: fnmatch(filename, pattern)
@@ -95,4 +94,3 @@
Module :mod:`glob`
Unix shell-style path expansion.
-
diff --git a/Doc/library/fractions.rst b/Doc/library/fractions.rst
--- a/Doc/library/fractions.rst
+++ b/Doc/library/fractions.rst
@@ -1,4 +1,3 @@
-
:mod:`fractions` --- Rational numbers
=====================================
@@ -8,6 +7,9 @@
.. sectionauthor:: Jeffrey Yasskin <jyasskin at gmail.com>
.. versionadded:: 2.6
+**Source code:** :source:`Lib/fractions.py`
+
+--------------
The :mod:`fractions` module provides support for rational number arithmetic.
diff --git a/Doc/library/ftplib.rst b/Doc/library/ftplib.rst
--- a/Doc/library/ftplib.rst
+++ b/Doc/library/ftplib.rst
@@ -9,6 +9,10 @@
pair: FTP; protocol
single: FTP; ftplib (standard module)
+**Source code:** :source:`Lib/ftplib.py`
+
+--------------
+
This module defines the class :class:`FTP` and a few related items. The
:class:`FTP` class implements the client side of the FTP protocol. You can use
this to write Python programs that perform a variety of automated FTP jobs, such
diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst
--- a/Doc/library/functions.rst
+++ b/Doc/library/functions.rst
@@ -624,9 +624,11 @@
.. function:: isinstance(object, classinfo)
Return true if the *object* argument is an instance of the *classinfo* argument,
- or of a (direct or indirect) subclass thereof. Also return true if *classinfo*
+ or of a (direct, indirect or :term:`virtual <abstract base class>`) subclass
+ thereof. Also return true if *classinfo*
is a type object (new-style class) and *object* is an object of that type or of
- a (direct or indirect) subclass thereof. If *object* is not a class instance or
+ a (direct, indirect or :term:`virtual <abstract base class>`) subclass
+ thereof. If *object* is not a class instance or
an object of the given type, the function always returns false. If *classinfo*
is neither a class object nor a type object, it may be a tuple of class or type
objects, or may recursively contain other such tuples (other sequence types are
@@ -639,7 +641,8 @@
.. function:: issubclass(class, classinfo)
- Return true if *class* is a subclass (direct or indirect) of *classinfo*. A
+ Return true if *class* is a subclass (direct, indirect or :term:`virtual
+ <abstract base class>`) of *classinfo*. A
class is considered a subclass of itself. *classinfo* may be a tuple of class
objects, in which case every entry in *classinfo* will be checked. In any other
case, a :exc:`TypeError` exception is raised.
diff --git a/Doc/library/functools.rst b/Doc/library/functools.rst
--- a/Doc/library/functools.rst
+++ b/Doc/library/functools.rst
@@ -8,18 +8,16 @@
.. moduleauthor:: Nick Coghlan <ncoghlan at gmail.com>
.. sectionauthor:: Peter Harris <scav at blueyonder.co.uk>
+.. versionadded:: 2.5
-.. versionadded:: 2.5
+**Source code:** :source:`Lib/functools.py`
+
+--------------
The :mod:`functools` module is for higher-order functions: functions that act on
or return other functions. In general, any callable object can be treated as a
function for the purposes of this module.
-.. seealso::
-
- Latest version of the `functools Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/functools.py?view=markup>`_
-
The :mod:`functools` module defines the following functions:
.. function:: cmp_to_key(func)
diff --git a/Doc/library/getopt.rst b/Doc/library/getopt.rst
--- a/Doc/library/getopt.rst
+++ b/Doc/library/getopt.rst
@@ -1,4 +1,3 @@
-
:mod:`getopt` --- C-style parser for command line options
=========================================================
@@ -6,6 +5,10 @@
:synopsis: Portable parser for command line options; support both short and long option
names.
+**Source code:** :source:`Lib/getopt.py`
+
+--------------
+
.. note::
The :mod:`getopt` module is a parser for command line options whose API is
designed to be familiar to users of the C :cfunc:`getopt` function. Users who
diff --git a/Doc/library/gettext.rst b/Doc/library/gettext.rst
--- a/Doc/library/gettext.rst
+++ b/Doc/library/gettext.rst
@@ -1,4 +1,3 @@
-
:mod:`gettext` --- Multilingual internationalization services
=============================================================
@@ -7,6 +6,9 @@
.. moduleauthor:: Barry A. Warsaw <barry at zope.com>
.. sectionauthor:: Barry A. Warsaw <barry at zope.com>
+**Source code:** :source:`Lib/gettext.py`
+
+--------------
The :mod:`gettext` module provides internationalization (I18N) and localization
(L10N) services for your Python modules and applications. It supports both the
diff --git a/Doc/library/glob.rst b/Doc/library/glob.rst
--- a/Doc/library/glob.rst
+++ b/Doc/library/glob.rst
@@ -1,4 +1,3 @@
-
:mod:`glob` --- Unix style pathname pattern expansion
=====================================================
@@ -8,6 +7,10 @@
.. index:: single: filenames; pathname expansion
+**Source code:** :source:`Lib/glob.py`
+
+--------------
+
The :mod:`glob` module finds all the pathnames matching a specified pattern
according to the rules used by the Unix shell. No tilde expansion is done, but
``*``, ``?``, and character ranges expressed with ``[]`` will be correctly
@@ -16,10 +19,6 @@
subshell. (For tilde and shell variable expansion, use
:func:`os.path.expanduser` and :func:`os.path.expandvars`.)
-.. seealso::
-
- Latest version of the `glob module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/glob.py?view=markup>`_
.. function:: glob(pathname)
diff --git a/Doc/library/gzip.rst b/Doc/library/gzip.rst
--- a/Doc/library/gzip.rst
+++ b/Doc/library/gzip.rst
@@ -4,6 +4,10 @@
.. module:: gzip
:synopsis: Interfaces for gzip compression and decompression using file objects.
+**Source code:** :source:`Lib/gzip.py`
+
+--------------
+
This module provides a simple interface to compress and decompress files just
like the GNU programs :program:`gzip` and :program:`gunzip` would.
diff --git a/Doc/library/hashlib.rst b/Doc/library/hashlib.rst
--- a/Doc/library/hashlib.rst
+++ b/Doc/library/hashlib.rst
@@ -1,4 +1,3 @@
-
:mod:`hashlib` --- Secure hashes and message digests
====================================================
@@ -14,6 +13,10 @@
single: message digest, MD5
single: secure hash algorithm, SHA1, SHA224, SHA256, SHA384, SHA512
+**Source code:** :source:`Lib/hashlib.py`
+
+--------------
+
This module implements a common interface to many different secure hash and
message digest algorithms. Included are the FIPS secure hash algorithms SHA1,
SHA224, SHA256, SHA384, and SHA512 (defined in FIPS 180-2) as well as RSA's MD5
diff --git a/Doc/library/heapq.rst b/Doc/library/heapq.rst
--- a/Doc/library/heapq.rst
+++ b/Doc/library/heapq.rst
@@ -10,14 +10,13 @@
.. versionadded:: 2.3
+**Source code:** :source:`Lib/heapq.py`
+
+--------------
+
This module provides an implementation of the heap queue algorithm, also known
as the priority queue algorithm.
-.. seealso::
-
- Latest version of the `heapq Python source code
- <http://svn.python.org/view/*checkout*/python/branches/release27-maint/Lib/heapq.py?content-type=text%2Fplain>`_
-
Heaps are binary trees for which every parent node has a value less than or
equal to any of its children. This implementation uses arrays for which
``heap[k] <= heap[2*k+1]`` and ``heap[k] <= heap[2*k+2]`` for all *k*, counting
diff --git a/Doc/library/hmac.rst b/Doc/library/hmac.rst
--- a/Doc/library/hmac.rst
+++ b/Doc/library/hmac.rst
@@ -1,4 +1,3 @@
-
:mod:`hmac` --- Keyed-Hashing for Message Authentication
========================================================
@@ -10,6 +9,10 @@
.. versionadded:: 2.2
+**Source code:** :source:`Lib/hmac.py`
+
+--------------
+
This module implements the HMAC algorithm as described by :rfc:`2104`.
diff --git a/Doc/library/htmllib.rst b/Doc/library/htmllib.rst
--- a/Doc/library/htmllib.rst
+++ b/Doc/library/htmllib.rst
@@ -165,6 +165,9 @@
Python 3.0. The :term:`2to3` tool will automatically adapt imports when
converting your sources to 3.0.
+**Source code:** :source:`Lib/htmlentitydefs.py`
+
+--------------
This module defines three dictionaries, ``name2codepoint``, ``codepoint2name``,
and ``entitydefs``. ``entitydefs`` is used by the :mod:`htmllib` module to
diff --git a/Doc/library/htmlparser.rst b/Doc/library/htmlparser.rst
--- a/Doc/library/htmlparser.rst
+++ b/Doc/library/htmlparser.rst
@@ -18,6 +18,10 @@
single: HTML
single: XHTML
+**Source code:** :source:`Lib/HTMLParser.py`
+
+--------------
+
This module defines a class :class:`HTMLParser` which serves as the basis for
parsing text files formatted in HTML (HyperText Mark-up Language) and XHTML.
Unlike the parser in :mod:`htmllib`, this parser is not based on the SGML parser
diff --git a/Doc/library/httplib.rst b/Doc/library/httplib.rst
--- a/Doc/library/httplib.rst
+++ b/Doc/library/httplib.rst
@@ -16,6 +16,10 @@
.. index:: module: urllib
+**Source code:** :source:`Lib/httplib.py`
+
+--------------
+
This module defines classes which implement the client side of the HTTP and
HTTPS protocols. It is normally not used directly --- the module :mod:`urllib`
uses it to handle URLs that use HTTP and HTTPS.
diff --git a/Doc/library/imaplib.rst b/Doc/library/imaplib.rst
--- a/Doc/library/imaplib.rst
+++ b/Doc/library/imaplib.rst
@@ -16,6 +16,10 @@
pair: IMAP4_SSL; protocol
pair: IMAP4_stream; protocol
+**Source code:** :source:`Lib/imaplib.py`
+
+--------------
+
This module defines three classes, :class:`IMAP4`, :class:`IMAP4_SSL` and
:class:`IMAP4_stream`, which encapsulate a connection to an IMAP4 server and
implement a large subset of the IMAP4rev1 client protocol as defined in
diff --git a/Doc/library/imghdr.rst b/Doc/library/imghdr.rst
--- a/Doc/library/imghdr.rst
+++ b/Doc/library/imghdr.rst
@@ -1,10 +1,12 @@
-
:mod:`imghdr` --- Determine the type of an image
================================================
.. module:: imghdr
:synopsis: Determine the type of image contained in a file or byte stream.
+**Source code:** :source:`Lib/imghdr.py`
+
+--------------
The :mod:`imghdr` module determines the type of image contained in a file or
byte stream.
diff --git a/Doc/library/inspect.rst b/Doc/library/inspect.rst
--- a/Doc/library/inspect.rst
+++ b/Doc/library/inspect.rst
@@ -1,4 +1,3 @@
-
:mod:`inspect` --- Inspect live objects
=======================================
@@ -10,6 +9,10 @@
.. versionadded:: 2.1
+**Source code:** :source:`Lib/inspect.py`
+
+--------------
+
The :mod:`inspect` module provides several useful functions to help get
information about live objects such as modules, classes, methods, functions,
tracebacks, frame objects, and code objects. For example, it can help you
diff --git a/Doc/library/keyword.rst b/Doc/library/keyword.rst
--- a/Doc/library/keyword.rst
+++ b/Doc/library/keyword.rst
@@ -1,10 +1,12 @@
-
:mod:`keyword` --- Testing for Python keywords
==============================================
.. module:: keyword
:synopsis: Test whether a string is a keyword in Python.
+**Source code:** :source:`Lib/keyword.py`
+
+--------------
This module allows a Python program to determine if a string is a keyword.
@@ -19,9 +21,3 @@
Sequence containing all the keywords defined for the interpreter. If any
keywords are defined to only be active when particular :mod:`__future__`
statements are in effect, these will be included as well.
-
-
-.. seealso::
-
- Latest version of the `keyword module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/keyword.py?view=markup>`_
diff --git a/Doc/library/linecache.rst b/Doc/library/linecache.rst
--- a/Doc/library/linecache.rst
+++ b/Doc/library/linecache.rst
@@ -6,17 +6,15 @@
:synopsis: This module provides random access to individual lines from text files.
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
+**Source code:** :source:`Lib/linecache.py`
+
+--------------
The :mod:`linecache` module allows one to get any line from any file, while
attempting to optimize internally, using a cache, the common case where many
lines are read from a single file. This is used by the :mod:`traceback` module
to retrieve source lines for inclusion in the formatted traceback.
-.. seealso::
-
- Latest version of the `linecache module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/linecache.py?view=markup>`_
-
The :mod:`linecache` module defines the following functions:
diff --git a/Doc/library/mailcap.rst b/Doc/library/mailcap.rst
--- a/Doc/library/mailcap.rst
+++ b/Doc/library/mailcap.rst
@@ -4,7 +4,9 @@
.. module:: mailcap
:synopsis: Mailcap file handling.
+**Source code:** :source:`Lib/mailcap.py`
+--------------
Mailcap files are used to configure how MIME-aware applications such as mail
readers and Web browsers react to files with different MIME types. (The name
diff --git a/Doc/library/mimetypes.rst b/Doc/library/mimetypes.rst
--- a/Doc/library/mimetypes.rst
+++ b/Doc/library/mimetypes.rst
@@ -9,6 +9,10 @@
.. index:: pair: MIME; content type
+**Source code:** :source:`Lib/mimetypes.py`
+
+--------------
+
The :mod:`mimetypes` module converts between a filename or URL and the MIME type
associated with the filename extension. Conversions are provided from filename
to MIME type and from MIME type to filename extension; encodings are not
diff --git a/Doc/library/modulefinder.rst b/Doc/library/modulefinder.rst
--- a/Doc/library/modulefinder.rst
+++ b/Doc/library/modulefinder.rst
@@ -1,15 +1,16 @@
-
:mod:`modulefinder` --- Find modules used by a script
=====================================================
+.. module:: modulefinder
+ :synopsis: Find modules used by a script.
.. sectionauthor:: A.M. Kuchling <amk at amk.ca>
-.. module:: modulefinder
- :synopsis: Find modules used by a script.
+.. versionadded:: 2.3
+**Source code:** :source:`Lib/modulefinder.py`
-.. versionadded:: 2.3
+--------------
This module provides a :class:`ModuleFinder` class that can be used to determine
the set of modules imported by a script. ``modulefinder.py`` can also be run as
diff --git a/Doc/library/netrc.rst b/Doc/library/netrc.rst
--- a/Doc/library/netrc.rst
+++ b/Doc/library/netrc.rst
@@ -10,6 +10,10 @@
.. versionadded:: 1.5.2
+**Source code:** :source:`Lib/netrc.py`
+
+--------------
+
The :class:`netrc` class parses and encapsulates the netrc file format used by
the Unix :program:`ftp` program and other FTP clients.
diff --git a/Doc/library/nntplib.rst b/Doc/library/nntplib.rst
--- a/Doc/library/nntplib.rst
+++ b/Doc/library/nntplib.rst
@@ -10,6 +10,10 @@
pair: NNTP; protocol
single: Network News Transfer Protocol
+**Source code:** :source:`Lib/nntplib.py`
+
+--------------
+
This module defines the class :class:`NNTP` which implements the client side of
the NNTP protocol. It can be used to implement a news reader or poster, or
automated news processors. For more information on NNTP (Network News Transfer
diff --git a/Doc/library/optparse.rst b/Doc/library/optparse.rst
--- a/Doc/library/optparse.rst
+++ b/Doc/library/optparse.rst
@@ -4,17 +4,18 @@
.. module:: optparse
:synopsis: Command-line option parsing library.
:deprecated:
+.. moduleauthor:: Greg Ward <gward at python.net>
+.. sectionauthor:: Greg Ward <gward at python.net>
+
+.. versionadded:: 2.3
.. deprecated:: 2.7
The :mod:`optparse` module is deprecated and will not be developed further;
development will continue with the :mod:`argparse` module.
-.. moduleauthor:: Greg Ward <gward at python.net>
-
-.. versionadded:: 2.3
-
-.. sectionauthor:: Greg Ward <gward at python.net>
-
+**Source code:** :source:`Lib/optparse.py`
+
+--------------
:mod:`optparse` is a more convenient, flexible, and powerful library for parsing
command-line options than the old :mod:`getopt` module. :mod:`optparse` uses a
diff --git a/Doc/library/pickletools.rst b/Doc/library/pickletools.rst
--- a/Doc/library/pickletools.rst
+++ b/Doc/library/pickletools.rst
@@ -8,6 +8,10 @@
.. versionadded:: 2.3
+**Source code:** :source:`Lib/pickletools.py`
+
+--------------
+
This module contains various constants relating to the intimate details of the
:mod:`pickle` module, some lengthy comments about the implementation, and a few
useful functions for analyzing pickled data. The contents of this module are
diff --git a/Doc/library/pipes.rst b/Doc/library/pipes.rst
--- a/Doc/library/pipes.rst
+++ b/Doc/library/pipes.rst
@@ -1,4 +1,3 @@
-
:mod:`pipes` --- Interface to shell pipelines
=============================================
@@ -7,6 +6,9 @@
:synopsis: A Python interface to Unix shell pipelines.
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
+**Source code:** :source:`Lib/pipes.py`
+
+--------------
The :mod:`pipes` module defines a class to abstract the concept of a *pipeline*
--- a sequence of converters from one file to another.
diff --git a/Doc/library/pkgutil.rst b/Doc/library/pkgutil.rst
--- a/Doc/library/pkgutil.rst
+++ b/Doc/library/pkgutil.rst
@@ -1,15 +1,18 @@
-
:mod:`pkgutil` --- Package extension utility
============================================
.. module:: pkgutil
:synopsis: Utilities for the import system.
+.. versionadded:: 2.3
+
+**Source code:** :source:`Lib/pkgutil.py`
+
+--------------
+
This module provides utilities for the import system, in particular package
support.
-.. versionadded:: 2.3
-
.. function:: extend_path(path, name)
diff --git a/Doc/library/platform.rst b/Doc/library/platform.rst
--- a/Doc/library/platform.rst
+++ b/Doc/library/platform.rst
@@ -9,6 +9,10 @@
.. versionadded:: 2.3
+**Source code:** :source:`Lib/platform.py`
+
+--------------
+
.. note::
Specific platforms listed alphabetically, with Linux included in the Unix
diff --git a/Doc/library/plistlib.rst b/Doc/library/plistlib.rst
--- a/Doc/library/plistlib.rst
+++ b/Doc/library/plistlib.rst
@@ -15,6 +15,10 @@
pair: plist; file
single: property list
+**Source code:** :source:`Lib/plistlib.py`
+
+--------------
+
This module provides an interface for reading and writing the "property list"
XML files used mainly by Mac OS X.
diff --git a/Doc/library/poplib.rst b/Doc/library/poplib.rst
--- a/Doc/library/poplib.rst
+++ b/Doc/library/poplib.rst
@@ -1,4 +1,3 @@
-
:mod:`poplib` --- POP3 protocol client
======================================
@@ -9,6 +8,10 @@
.. index:: pair: POP3; protocol
+**Source code:** :source:`Lib/poplib.py`
+
+--------------
+
This module defines a class, :class:`POP3`, which encapsulates a connection to a
POP3 server and implements the protocol as defined in :rfc:`1725`. The
:class:`POP3` class supports both the minimal and optional command sets.
diff --git a/Doc/library/pprint.rst b/Doc/library/pprint.rst
--- a/Doc/library/pprint.rst
+++ b/Doc/library/pprint.rst
@@ -1,4 +1,3 @@
-
:mod:`pprint` --- Data pretty printer
=====================================
@@ -7,6 +6,9 @@
.. moduleauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/pprint.py`
+
+--------------
The :mod:`pprint` module provides a capability to "pretty-print" arbitrary
Python data structures in a form which can be used as input to the interpreter.
@@ -28,10 +30,6 @@
.. versionchanged:: 2.6
Added support for :class:`set` and :class:`frozenset`.
-.. seealso::
-
- Latest version of the `pprint module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/pprint.py?view=markup>`_
The :mod:`pprint` module defines one class:
diff --git a/Doc/library/profile.rst b/Doc/library/profile.rst
--- a/Doc/library/profile.rst
+++ b/Doc/library/profile.rst
@@ -1,4 +1,3 @@
-
.. _profile:
********************
@@ -10,6 +9,9 @@
.. module:: profile
:synopsis: Python source profiler.
+**Source code:** :source:`Lib/profile.py` and :source:`Lib/pstats.py`
+
+--------------
.. _profiler-introduction:
diff --git a/Doc/library/py_compile.rst b/Doc/library/py_compile.rst
--- a/Doc/library/py_compile.rst
+++ b/Doc/library/py_compile.rst
@@ -8,6 +8,10 @@
.. index:: pair: file; byte-code
+**Source code:** :source:`Lib/py_compile.py`
+
+--------------
+
The :mod:`py_compile` module provides a function to generate a byte-code file
from a source file, and another function used when the module source file is
invoked as a script.
diff --git a/Doc/library/pyclbr.rst b/Doc/library/pyclbr.rst
--- a/Doc/library/pyclbr.rst
+++ b/Doc/library/pyclbr.rst
@@ -1,4 +1,3 @@
-
:mod:`pyclbr` --- Python class browser support
==============================================
@@ -6,6 +5,9 @@
:synopsis: Supports information extraction for a Python class browser.
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/pyclbr.py`
+
+--------------
The :mod:`pyclbr` module can be used to determine some limited information
about the classes, methods and top-level functions defined in a module. The
diff --git a/Doc/library/pydoc.rst b/Doc/library/pydoc.rst
--- a/Doc/library/pydoc.rst
+++ b/Doc/library/pydoc.rst
@@ -1,4 +1,3 @@
-
:mod:`pydoc` --- Documentation generator and online help system
===============================================================
@@ -15,6 +14,10 @@
single: documentation; online
single: help; online
+**Source code:** :source:`Lib/pydoc.py`
+
+--------------
+
The :mod:`pydoc` module automatically generates documentation from Python
modules. The documentation can be presented as pages of text on the console,
served to a Web browser, or saved to HTML files.
diff --git a/Doc/library/queue.rst b/Doc/library/queue.rst
--- a/Doc/library/queue.rst
+++ b/Doc/library/queue.rst
@@ -9,6 +9,9 @@
:term:`2to3` tool will automatically adapt imports when converting your
sources to 3.0.
+**Source code:** :source:`Lib/Queue.py`
+
+--------------
The :mod:`Queue` module implements multi-producer, multi-consumer queues.
It is especially useful in threaded programming when information must be
@@ -24,11 +27,6 @@
the entries are kept sorted (using the :mod:`heapq` module) and the
lowest valued entry is retrieved first.
-.. seealso::
-
- Latest version of the `Queue module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/Queue.py?view=markup>`_.
-
The :mod:`Queue` module defines the following classes and exceptions:
.. class:: Queue(maxsize=0)
diff --git a/Doc/library/quopri.rst b/Doc/library/quopri.rst
--- a/Doc/library/quopri.rst
+++ b/Doc/library/quopri.rst
@@ -1,4 +1,3 @@
-
:mod:`quopri` --- Encode and decode MIME quoted-printable data
==============================================================
@@ -10,6 +9,10 @@
pair: quoted-printable; encoding
single: MIME; quoted-printable encoding
+**Source code:** :source:`Lib/quopri.py`
+
+--------------
+
This module performs quoted-printable transport encoding and decoding, as
defined in :rfc:`1521`: "MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing the Format of Internet Message Bodies".
@@ -18,11 +21,6 @@
:mod:`base64` module is more compact if there are many such characters, as when
sending a graphics file.
-.. seealso::
-
- Latest version of the `quopri module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/quopri.py?view=markup>`_
-
.. function:: decode(input, output[,header])
Decode the contents of the *input* file and write the resulting decoded binary
diff --git a/Doc/library/random.rst b/Doc/library/random.rst
--- a/Doc/library/random.rst
+++ b/Doc/library/random.rst
@@ -1,19 +1,16 @@
-
:mod:`random` --- Generate pseudo-random numbers
================================================
.. module:: random
:synopsis: Generate pseudo-random numbers with various common distributions.
+**Source code:** :source:`Lib/random.py`
+
+--------------
This module implements pseudo-random number generators for various
distributions.
-.. seealso::
-
- Latest version of the `random module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/random.py?view=markup>`_
-
For integers, uniform selection from a range. For sequences, uniform selection
of a random element, a function to generate a random permutation of a list
in-place, and a function for random sampling without replacement.
diff --git a/Doc/library/repr.rst b/Doc/library/repr.rst
--- a/Doc/library/repr.rst
+++ b/Doc/library/repr.rst
@@ -1,4 +1,3 @@
-
:mod:`repr` --- Alternate :func:`repr` implementation
=====================================================
@@ -11,15 +10,14 @@
:term:`2to3` tool will automatically adapt imports when converting your
sources to 3.0.
+**Source code:** :source:`Lib/repr.py`
+
+--------------
+
The :mod:`repr` module provides a means for producing object representations
with limits on the size of the resulting strings. This is used in the Python
debugger and may be useful in other contexts as well.
-.. seealso::
-
- Latest version of the `repr module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/repr.py?view=markup>`_
-
This module provides a class, an instance, and a function:
diff --git a/Doc/library/rlcompleter.rst b/Doc/library/rlcompleter.rst
--- a/Doc/library/rlcompleter.rst
+++ b/Doc/library/rlcompleter.rst
@@ -1,4 +1,3 @@
-
:mod:`rlcompleter` --- Completion function for GNU readline
===========================================================
@@ -6,6 +5,9 @@
:synopsis: Python identifier completion, suitable for the GNU readline library.
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
+**Source code:** :source:`Lib/rlcompleter.py`
+
+--------------
The :mod:`rlcompleter` module defines a completion function suitable for the
:mod:`readline` module by completing valid Python identifiers and keywords.
diff --git a/Doc/library/runpy.rst b/Doc/library/runpy.rst
--- a/Doc/library/runpy.rst
+++ b/Doc/library/runpy.rst
@@ -8,6 +8,10 @@
.. versionadded:: 2.5
+**Source code:** :source:`Lib/runpy.py`
+
+--------------
+
The :mod:`runpy` module is used to locate and run Python modules without
importing them first. Its main use is to implement the :option:`-m` command
line switch that allows scripts to be located using the Python module
diff --git a/Doc/library/sched.rst b/Doc/library/sched.rst
--- a/Doc/library/sched.rst
+++ b/Doc/library/sched.rst
@@ -7,14 +7,13 @@
.. index:: single: event scheduling
+**Source code:** :source:`Lib/sched.py`
+
+--------------
+
The :mod:`sched` module defines a class which implements a general purpose event
scheduler:
-.. seealso::
-
- Latest version of the `sched module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/sched.py?view=markup>`_
-
.. class:: scheduler(timefunc, delayfunc)
The :class:`scheduler` class defines a generic interface to scheduling events.
diff --git a/Doc/library/shelve.rst b/Doc/library/shelve.rst
--- a/Doc/library/shelve.rst
+++ b/Doc/library/shelve.rst
@@ -7,16 +7,16 @@
.. index:: module: pickle
+**Source code:** :source:`Lib/shelve.py`
+
+--------------
+
A "shelf" is a persistent, dictionary-like object. The difference with "dbm"
databases is that the values (not the keys!) in a shelf can be essentially
arbitrary Python objects --- anything that the :mod:`pickle` module can handle.
This includes most class instances, recursive data types, and objects containing
lots of shared sub-objects. The keys are ordinary strings.
-.. seealso::
-
- Latest version of the `shelve module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/shelve.py?view=markup>`_
.. function:: open(filename[, flag='c'[, protocol=None[, writeback=False]]])
diff --git a/Doc/library/shlex.rst b/Doc/library/shlex.rst
--- a/Doc/library/shlex.rst
+++ b/Doc/library/shlex.rst
@@ -1,4 +1,3 @@
-
:mod:`shlex` --- Simple lexical analysis
========================================
@@ -12,6 +11,11 @@
.. versionadded:: 1.5.2
+**Source code:** :source:`Lib/shlex.py`
+
+--------------
+
+
The :class:`shlex` class makes it easy to write lexical analyzers for simple
syntaxes resembling that of the Unix shell. This will often be useful for
writing minilanguages, (for example, in run control files for Python
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst
--- a/Doc/library/shutil.rst
+++ b/Doc/library/shutil.rst
@@ -1,4 +1,3 @@
-
:mod:`shutil` --- High-level file operations
============================================
@@ -11,16 +10,15 @@
single: file; copying
single: copying files
+**Source code:** :source:`Lib/shutil.py`
+
+--------------
+
The :mod:`shutil` module offers a number of high-level operations on files and
collections of files. In particular, functions are provided which support file
copying and removal. For operations on individual files, see also the
:mod:`os` module.
-.. seealso::
-
- Latest version of the `shutil module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/shutil.py?view=markup>`_
-
.. warning::
Even the higher-level file copying functions (:func:`copy`, :func:`copy2`)
@@ -280,6 +278,8 @@
*owner* and *group* are used when creating a tar archive. By default,
uses the current owner and group.
+ *logger* is an instance of :class:`logging.Logger`.
+
.. versionadded:: 2.7
diff --git a/Doc/library/simplexmlrpcserver.rst b/Doc/library/simplexmlrpcserver.rst
--- a/Doc/library/simplexmlrpcserver.rst
+++ b/Doc/library/simplexmlrpcserver.rst
@@ -14,6 +14,10 @@
.. versionadded:: 2.2
+**Source code:** :source:`Lib/SimpleXMLRPCServer.py`
+
+--------------
+
The :mod:`SimpleXMLRPCServer` module provides a basic server framework for
XML-RPC servers written in Python. Servers can either be free standing, using
:class:`SimpleXMLRPCServer`, or embedded in a CGI environment, using
diff --git a/Doc/library/site.rst b/Doc/library/site.rst
--- a/Doc/library/site.rst
+++ b/Doc/library/site.rst
@@ -1,17 +1,22 @@
-
:mod:`site` --- Site-specific configuration hook
================================================
.. module:: site
- :synopsis: A standard way to reference site-specific modules.
+ :synopsis: Module responsible for site-specific configuration.
+**Source code:** :source:`Lib/site.py`
+
+--------------
+
+.. highlightlang:: none
**This module is automatically imported during initialization.** The automatic
import can be suppressed using the interpreter's :option:`-S` option.
.. index:: triple: module; search; path
-Importing this module will append site-specific paths to the module search path.
+Importing this module will append site-specific paths to the module search path
+and add a few builtins.
.. index::
pair: site-python; directory
@@ -26,11 +31,11 @@
if it refers to an existing directory, and if so, adds it to ``sys.path`` and
also inspects the newly added path for configuration files.
-A path configuration file is a file whose name has the form :file:`package.pth`
+A path configuration file is a file whose name has the form :file:`{name}.pth`
and exists in one of the four directories mentioned above; its contents are
additional items (one per line) to be added to ``sys.path``. Non-existing items
-are never added to ``sys.path``, but no check is made that the item refers to a
-directory (rather than a file). No item is added to ``sys.path`` more than
+are never added to ``sys.path``, and no check is made that the item refers to a
+directory rather than a file. No item is added to ``sys.path`` more than
once. Blank lines and lines beginning with ``#`` are skipped. Lines starting
with ``import`` (followed by space or tab) are executed.
@@ -43,8 +48,7 @@
For example, suppose ``sys.prefix`` and ``sys.exec_prefix`` are set to
:file:`/usr/local`. The Python X.Y library is then installed in
-:file:`/usr/local/lib/python{X.Y}` (where only the first three characters of
-``sys.version`` are used to form the installation path name). Suppose this has
+:file:`/usr/local/lib/python{X.Y}`. Suppose this has
a subdirectory :file:`/usr/local/lib/python{X.Y}/site-packages` with three
subsubdirectories, :file:`foo`, :file:`bar` and :file:`spam`, and two path
configuration files, :file:`foo.pth` and :file:`bar.pth`. Assume
@@ -77,86 +81,132 @@
After these path manipulations, an attempt is made to import a module named
:mod:`sitecustomize`, which can perform arbitrary site-specific customizations.
-If this import fails with an :exc:`ImportError` exception, it is silently
-ignored.
+It is typically created by a system administrator in the site-packages
+directory. If this import fails with an :exc:`ImportError` exception, it is
+silently ignored.
-.. index:: module: sitecustomize
+.. index:: module: usercustomize
+
+After this, an attempt is made to import a module named :mod:`usercustomize`,
+which can perform arbitrary user-specific customizations, if
+:data:`ENABLE_USER_SITE` is true. This file is intended to be created in the
+user site-packages directory (see below), which is part of ``sys.path`` unless
+disabled by :option:`-s`. An :exc:`ImportError` will be silently ignored.
Note that for some non-Unix systems, ``sys.prefix`` and ``sys.exec_prefix`` are
empty, and the path manipulations are skipped; however the import of
-:mod:`sitecustomize` is still attempted.
+:mod:`sitecustomize` and :mod:`usercustomize` is still attempted.
.. data:: PREFIXES
- A list of prefixes for site package directories
+ A list of prefixes for site-packages directories.
.. versionadded:: 2.6
.. data:: ENABLE_USER_SITE
- Flag showing the status of the user site directory. True means the
- user site directory is enabled and added to sys.path. When the flag
- is None the user site directory is disabled for security reasons.
+ Flag showing the status of the user site-packages directory. ``True`` means
+ that it is enabled and was added to ``sys.path``. ``False`` means that it
+ was disabled by user request (with :option:`-s` or
+ :envvar:`PYTHONNOUSERSITE`). ``None`` means it was disabled for security
+ reasons (mismatch between user or group id and effective id) or by an
+ administrator.
.. versionadded:: 2.6
.. data:: USER_SITE
- Path to the user site directory for the current Python version or None
+ Path to the user site-packages for the running Python. Can be ``None`` if
+ :func:`getusersitepackages` hasn't been called yet. Default value is
+ :file:`~/.local/lib/python{X.Y}/site-packages` for UNIX and non-framework Mac
+ OS X builds, :file:`~/Library/Python/{X.Y}/lib/python/site-packages` for Mac
+ framework builds, and :file:`{%APPDATA%}\\Python\\Python{XY}\\site-packages`
+ on Windows. This directory is a site directory, which means that
+ :file:`.pth` files in it will be processed.
.. versionadded:: 2.6
.. data:: USER_BASE
- Path to the base directory for user site directories
+ Path to the base directory for the user site-packages. Can be ``None`` if
+ :func:`getuserbase` hasn't been called yet. Default value is
+ :file:`~/.local` for UNIX and Mac OS X non-framework builds,
+ :file:`~/Library/Python/{X.Y}` for Mac framework builds, and
+ :file:`{%APPDATA%}\\Python` for Windows. This value is used by Distutils to
+ compute the installation directories for scripts, data files, Python modules,
+ etc. for the :ref:`user installation scheme <inst-alt-install-user>`. See
+ also :envvar:`PYTHONUSERBASE`.
.. versionadded:: 2.6
-.. envvar:: PYTHONNOUSERSITE
-
- .. versionadded:: 2.6
-
-
-.. envvar:: PYTHONUSERBASE
-
- .. versionadded:: 2.6
-
-
.. function:: addsitedir(sitedir, known_paths=None)
- Adds a directory to sys.path and processes its pth files.
+ Add a directory to sys.path and process its :file:`.pth` files. Typically
+ used in :mod:`sitecustomize` or :mod:`usercustomize` (see above).
+
.. function:: getsitepackages()
- Returns a list containing all global site-packages directories
- (and possibly site-python).
+ Return a list containing all global site-packages directories (and possibly
+ site-python).
.. versionadded:: 2.7
+
.. function:: getuserbase()
- Returns the "user base" directory path.
-
- The "user base" directory can be used to store data. If the global
- variable ``USER_BASE`` is not initialized yet, this function will also set
- it.
+ Return the path of the user base directory, :data:`USER_BASE`. If it is not
+ initialized yet, this function will also set it, respecting
+ :envvar:`PYTHONUSERBASE`.
.. versionadded:: 2.7
+
.. function:: getusersitepackages()
- Returns the user-specific site-packages directory path.
-
- If the global variable ``USER_SITE`` is not initialized yet, this
- function will also set it.
+ Return the path of the user-specific site-packages directory,
+ :data:`USER_SITE`. If it is not initialized yet, this function will also set
+ it, respecting :envvar:`PYTHONNOUSERSITE` and :data:`USER_BASE`.
.. versionadded:: 2.7
-.. XXX Update documentation
-.. XXX document python -m site --user-base --user-site
+The :mod:`site` module also provides a way to get the user directories from the
+command line:
+
+.. code-block:: sh
+
+ $ python3 -m site --user-site
+ /home/user/.local/lib/python3.3/site-packages
+
+.. program:: site
+
+If it is called without arguments, it will print the contents of
+:data:`sys.path` on the standard output, followed by the value of
+:data:`USER_BASE` and whether the directory exists, then the same thing for
+:data:`USER_SITE`, and finally the value of :data:`ENABLE_USER_SITE`.
+
+.. cmdoption:: --user-base
+
+ Print the path to the user base directory.
+
+.. cmdoption:: --user-site
+
+ Print the path to the user site-packages directory.
+
+If both options are given, user base and user site will be printed (always in
+this order), separated by :data:`os.pathsep`.
+
+If any option is given, the script will exit with one of these values: ``O`` if
+the user site-packages directory is enabled, ``1`` if it was disabled by the
+user, ``2`` if it is disabled for security reasons or by an administrator, and a
+value greater than 2 if there is an error.
+
+.. seealso::
+
+ :pep:`370` -- Per user site-packages directory
diff --git a/Doc/library/smtpd.rst b/Doc/library/smtpd.rst
--- a/Doc/library/smtpd.rst
+++ b/Doc/library/smtpd.rst
@@ -7,8 +7,9 @@
.. moduleauthor:: Barry Warsaw <barry at zope.com>
.. sectionauthor:: Moshe Zadka <moshez at moshez.org>
+**Source code:** :source:`Lib/smtpd.py`
-
+--------------
This module offers several classes to implement SMTP servers. One is a generic
do-nothing implementation, which can be overridden, while the other two offer
diff --git a/Doc/library/smtplib.rst b/Doc/library/smtplib.rst
--- a/Doc/library/smtplib.rst
+++ b/Doc/library/smtplib.rst
@@ -1,4 +1,3 @@
-
:mod:`smtplib` --- SMTP protocol client
=======================================
@@ -11,6 +10,10 @@
pair: SMTP; protocol
single: Simple Mail Transfer Protocol
+**Source code:** :source:`Lib/smtplib.py`
+
+--------------
+
The :mod:`smtplib` module defines an SMTP client session object that can be used
to send mail to any Internet machine with an SMTP or ESMTP listener daemon. For
details of SMTP and ESMTP operation, consult :rfc:`821` (Simple Mail Transfer
diff --git a/Doc/library/sndhdr.rst b/Doc/library/sndhdr.rst
--- a/Doc/library/sndhdr.rst
+++ b/Doc/library/sndhdr.rst
@@ -1,4 +1,3 @@
-
:mod:`sndhdr` --- Determine type of sound file
==============================================
@@ -11,6 +10,10 @@
single: A-LAW
single: u-LAW
+**Source code:** :source:`Lib/sndhdr.py`
+
+--------------
+
The :mod:`sndhdr` provides utility functions which attempt to determine the type
of sound data which is in a file. When these functions are able to determine
what type of sound data is stored in a file, they return a tuple ``(type,
diff --git a/Doc/library/socketserver.rst b/Doc/library/socketserver.rst
--- a/Doc/library/socketserver.rst
+++ b/Doc/library/socketserver.rst
@@ -1,4 +1,3 @@
-
:mod:`SocketServer` --- A framework for network servers
=======================================================
@@ -11,6 +10,9 @@
Python 3.0. The :term:`2to3` tool will automatically adapt imports when
converting your sources to 3.0.
+**Source code:** :source:`Lib/SocketServer.py`
+
+--------------
The :mod:`SocketServer` module simplifies the task of writing network servers.
diff --git a/Doc/library/ssl.rst b/Doc/library/ssl.rst
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@ -5,9 +5,6 @@
:synopsis: TLS/SSL wrapper for socket objects
.. moduleauthor:: Bill Janssen <bill.janssen at gmail.com>
-
-.. versionadded:: 2.6
-
.. sectionauthor:: Bill Janssen <bill.janssen at gmail.com>
@@ -15,6 +12,12 @@
.. index:: TLS, SSL, Transport Layer Security, Secure Sockets Layer
+.. versionadded:: 2.6
+
+**Source code:** :source:`Lib/ssl.py`
+
+--------------
+
This module provides access to Transport Layer Security (often known as "Secure
Sockets Layer") encryption and peer authentication facilities for network
sockets, both client-side and server-side. This module uses the OpenSSL
diff --git a/Doc/library/stat.rst b/Doc/library/stat.rst
--- a/Doc/library/stat.rst
+++ b/Doc/library/stat.rst
@@ -1,4 +1,3 @@
-
:mod:`stat` --- Interpreting :func:`stat` results
=================================================
@@ -6,6 +5,9 @@
:synopsis: Utilities for interpreting the results of os.stat(), os.lstat() and os.fstat().
.. sectionauthor:: Skip Montanaro <skip at automatrix.com>
+**Source code:** :source:`Lib/stat.py`
+
+--------------
The :mod:`stat` module defines constants and functions for interpreting the
results of :func:`os.stat`, :func:`os.fstat` and :func:`os.lstat` (if they
diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
--- a/Doc/library/stdtypes.rst
+++ b/Doc/library/stdtypes.rst
@@ -2406,7 +2406,7 @@
.. method:: file.readline([size])
Read one entire line from the file. A trailing newline character is kept in
- the string (but may be absent when a file ends with an incomplete line). [#]_
+ the string (but may be absent when a file ends with an incomplete line). [6]_
If the *size* argument is present and non-negative, it is a maximum byte
count (including the trailing newline) and an incomplete line may be
returned. When *size* is not 0, an empty string is returned *only* when EOF
@@ -3062,7 +3062,7 @@
.. [5] To format only a tuple you should therefore provide a singleton tuple whose only
element is the tuple to be formatted.
-.. [#] The advantage of leaving the newline on is that returning an empty string is
+.. [6] The advantage of leaving the newline on is that returning an empty string is
then an unambiguous EOF indication. It is also possible (in cases where it
might matter, for example, if you want to make an exact copy of a file while
scanning its lines) to tell whether the last line of a file ended in a newline
diff --git a/Doc/library/string.rst b/Doc/library/string.rst
--- a/Doc/library/string.rst
+++ b/Doc/library/string.rst
@@ -7,6 +7,10 @@
.. index:: module: re
+**Source code:** :source:`Lib/string.py`
+
+--------------
+
The :mod:`string` module contains a number of useful constants and
classes, as well as some deprecated legacy functions that are also
available as methods on strings. In addition, Python's built-in string
@@ -17,12 +21,6 @@
:ref:`string-formatting` section. Also, see the :mod:`re` module for
string functions based on regular expressions.
-.. seealso::
-
- Latest version of the `string module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/string.py?view=markup>`_
-
-
String constants
----------------
diff --git a/Doc/library/sunau.rst b/Doc/library/sunau.rst
--- a/Doc/library/sunau.rst
+++ b/Doc/library/sunau.rst
@@ -1,4 +1,3 @@
-
:mod:`sunau` --- Read and write Sun AU files
============================================
@@ -6,6 +5,9 @@
:synopsis: Provide an interface to the Sun AU sound format.
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
+**Source code:** :source:`Lib/sunau.py`
+
+--------------
The :mod:`sunau` module provides a convenient interface to the Sun AU sound
format. Note that this module is interface-compatible with the modules
diff --git a/Doc/library/symbol.rst b/Doc/library/symbol.rst
--- a/Doc/library/symbol.rst
+++ b/Doc/library/symbol.rst
@@ -1,4 +1,3 @@
-
:mod:`symbol` --- Constants used with Python parse trees
========================================================
@@ -6,6 +5,9 @@
:synopsis: Constants representing internal nodes of the parse tree.
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/symbol.py`
+
+--------------
This module provides constants which represent the numeric values of internal
nodes of the parse tree. Unlike most Python constants, these use lower-case
diff --git a/Doc/library/sysconfig.rst b/Doc/library/sysconfig.rst
--- a/Doc/library/sysconfig.rst
+++ b/Doc/library/sysconfig.rst
@@ -5,10 +5,15 @@
:synopsis: Python's configuration information
.. moduleauthor:: Tarek Ziade <tarek at ziade.org>
.. sectionauthor:: Tarek Ziade <tarek at ziade.org>
-.. versionadded:: 2.7
.. index::
single: configuration information
+.. versionadded:: 2.7
+
+**Source code:** :source:`Lib/sysconfig.py`
+
+--------------
+
The :mod:`sysconfig` module provides access to Python's configuration
information like the list of installation paths and the configuration variables
relevant for the current platform.
diff --git a/Doc/library/tabnanny.rst b/Doc/library/tabnanny.rst
--- a/Doc/library/tabnanny.rst
+++ b/Doc/library/tabnanny.rst
@@ -9,6 +9,10 @@
.. rudimentary documentation based on module comments
+**Source code:** :source:`Lib/tabnanny.py`
+
+--------------
+
For the time being this module is intended to be called as a script. However it
is possible to import it into an IDE and use the function :func:`check`
described below.
diff --git a/Doc/library/tarfile.rst b/Doc/library/tarfile.rst
--- a/Doc/library/tarfile.rst
+++ b/Doc/library/tarfile.rst
@@ -1,5 +1,3 @@
-.. _tarfile-mod:
-
:mod:`tarfile` --- Read and write tar archive files
===================================================
@@ -12,6 +10,9 @@
.. moduleauthor:: Lars Gustäbel <lars at gustaebel.de>
.. sectionauthor:: Lars Gustäbel <lars at gustaebel.de>
+**Source code:** :source:`Lib/tarfile.py`
+
+--------------
The :mod:`tarfile` module makes it possible to read and write tar
archives, including those using gzip or bz2 compression.
diff --git a/Doc/library/telnetlib.rst b/Doc/library/telnetlib.rst
--- a/Doc/library/telnetlib.rst
+++ b/Doc/library/telnetlib.rst
@@ -1,4 +1,3 @@
-
:mod:`telnetlib` --- Telnet client
==================================
@@ -9,6 +8,10 @@
.. index:: single: protocol; Telnet
+**Source code:** :source:`Lib/telnetlib.py`
+
+--------------
+
The :mod:`telnetlib` module provides a :class:`Telnet` class that implements the
Telnet protocol. See :rfc:`854` for details about the protocol. In addition, it
provides symbolic constants for the protocol characters (see below), and for the
diff --git a/Doc/library/tempfile.rst b/Doc/library/tempfile.rst
--- a/Doc/library/tempfile.rst
+++ b/Doc/library/tempfile.rst
@@ -1,4 +1,3 @@
-
:mod:`tempfile` --- Generate temporary files and directories
============================================================
@@ -13,6 +12,10 @@
pair: temporary; file name
pair: temporary; file
+**Source code:** :source:`Lib/tempfile.py`
+
+--------------
+
This module generates temporary files and directories. It works on all
supported platforms.
diff --git a/Doc/library/textwrap.rst b/Doc/library/textwrap.rst
--- a/Doc/library/textwrap.rst
+++ b/Doc/library/textwrap.rst
@@ -1,4 +1,3 @@
-
:mod:`textwrap` --- Text wrapping and filling
=============================================
@@ -7,8 +6,11 @@
.. moduleauthor:: Greg Ward <gward at python.net>
.. sectionauthor:: Greg Ward <gward at python.net>
+.. versionadded:: 2.3
-.. versionadded:: 2.3
+**Source code:** :source:`Lib/textwrap.py`
+
+--------------
The :mod:`textwrap` module provides two convenience functions, :func:`wrap` and
:func:`fill`, as well as :class:`TextWrapper`, the class that does all the work,
@@ -16,11 +18,6 @@
or two text strings, the convenience functions should be good enough;
otherwise, you should use an instance of :class:`TextWrapper` for efficiency.
-.. seealso::
-
- Latest version of the `textwrap module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/textwrap.py?view=markup>`_
-
.. function:: wrap(text[, width[, ...]])
Wraps the single paragraph in *text* (a string) so every line is at most *width*
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -4,6 +4,9 @@
.. module:: threading
:synopsis: Higher-level threading interface.
+**Source code:** :source:`Lib/threading.py`
+
+--------------
This module constructs higher-level threading interfaces on top of the lower
level :mod:`thread` module.
@@ -36,11 +39,6 @@
:mod:`multiprocessing`. However, threading is still an appropriate model
if you want to run multiple I/O-bound tasks simultaneously.
-.. seealso::
-
- Latest version of the `threading module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/threading.py?view=markup>`_
-
This module defines the following functions and objects:
diff --git a/Doc/library/timeit.rst b/Doc/library/timeit.rst
--- a/Doc/library/timeit.rst
+++ b/Doc/library/timeit.rst
@@ -1,4 +1,3 @@
-
:mod:`timeit` --- Measure execution time of small code snippets
===============================================================
@@ -12,6 +11,10 @@
single: Benchmarking
single: Performance
+**Source code:** :source:`Lib/timeit.py`
+
+--------------
+
This module provides a simple way to time small bits of Python code. It has both
command line as well as callable interfaces. It avoids a number of common traps
for measuring execution times. See also Tim Peters' introduction to the
diff --git a/Doc/library/token.rst b/Doc/library/token.rst
--- a/Doc/library/token.rst
+++ b/Doc/library/token.rst
@@ -1,4 +1,3 @@
-
:mod:`token` --- Constants used with Python parse trees
=======================================================
@@ -6,6 +5,9 @@
:synopsis: Constants representing terminal nodes of the parse tree.
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/token.py`
+
+--------------
This module provides constants which represent the numeric values of leaf nodes
of the parse tree (terminal tokens). Refer to the file :file:`Grammar/Grammar`
diff --git a/Doc/library/tokenize.rst b/Doc/library/tokenize.rst
--- a/Doc/library/tokenize.rst
+++ b/Doc/library/tokenize.rst
@@ -1,4 +1,3 @@
-
:mod:`tokenize` --- Tokenizer for Python source
===============================================
@@ -7,17 +6,15 @@
.. moduleauthor:: Ka Ping Yee
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/tokenize.py`
+
+--------------
The :mod:`tokenize` module provides a lexical scanner for Python source code,
implemented in Python. The scanner in this module returns comments as tokens as
well, making it useful for implementing "pretty-printers," including colorizers
for on-screen displays.
-.. seealso::
-
- Latest version of the `tokenize module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/tokenize.py?view=markup>`_
-
The primary entry point is a :term:`generator`:
.. function:: generate_tokens(readline)
diff --git a/Doc/library/trace.rst b/Doc/library/trace.rst
--- a/Doc/library/trace.rst
+++ b/Doc/library/trace.rst
@@ -1,21 +1,18 @@
-
:mod:`trace` --- Trace or track Python statement execution
==========================================================
.. module:: trace
:synopsis: Trace or track Python statement execution.
+**Source code:** :source:`Lib/trace.py`
+
+--------------
The :mod:`trace` module allows you to trace program execution, generate
annotated statement coverage listings, print caller/callee relationships and
list functions executed during a program run. It can be used in another program
or from the command line.
-.. seealso::
-
- Latest version of the `trace module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/trace.py?view=markup>`_
-
.. _trace-cli:
Command-Line Usage
diff --git a/Doc/library/types.rst b/Doc/library/types.rst
--- a/Doc/library/types.rst
+++ b/Doc/library/types.rst
@@ -4,6 +4,9 @@
.. module:: types
:synopsis: Names for built-in types.
+**Source code:** :source:`Lib/types.py`
+
+--------------
This module defines names for some object types that are used by the standard
Python interpreter, but not for the types defined by various extension modules.
diff --git a/Doc/library/urlparse.rst b/Doc/library/urlparse.rst
--- a/Doc/library/urlparse.rst
+++ b/Doc/library/urlparse.rst
@@ -17,6 +17,9 @@
The :term:`2to3` tool will automatically adapt imports when converting
your sources to 3.0.
+**Source code:** :source:`Lib/urlparse.py`
+
+--------------
This module defines a standard interface to break Uniform Resource Locator (URL)
strings up in components (addressing scheme, network location, path etc.), to
@@ -33,11 +36,6 @@
.. versionadded:: 2.5
Support for the ``sftp`` and ``sips`` schemes.
-.. seealso::
-
- Latest version of the `urlparse module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/urlparse.py?view=markup>`_
-
The :mod:`urlparse` module defines the following functions:
diff --git a/Doc/library/userdict.rst b/Doc/library/userdict.rst
--- a/Doc/library/userdict.rst
+++ b/Doc/library/userdict.rst
@@ -1,4 +1,3 @@
-
:mod:`UserDict` --- Class wrapper for dictionary objects
========================================================
@@ -6,6 +5,10 @@
:synopsis: Class wrapper for dictionary objects.
+**Source code:** :source:`Lib/UserDict.py`
+
+--------------
+
The module defines a mixin, :class:`DictMixin`, defining all dictionary methods
for classes that already have a minimum mapping interface. This greatly
simplifies writing classes that need to be substitutable for dictionaries (such
@@ -19,11 +22,6 @@
sub-classes that obtained new behaviors by overriding existing methods or adding
new ones.
-.. seealso::
-
- Latest version of the `UserDict Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/UserDict.py?view=markup>`_
-
The :mod:`UserDict` module defines the :class:`UserDict` class and
:class:`DictMixin`:
diff --git a/Doc/library/uu.rst b/Doc/library/uu.rst
--- a/Doc/library/uu.rst
+++ b/Doc/library/uu.rst
@@ -1,4 +1,3 @@
-
:mod:`uu` --- Encode and decode uuencode files
==============================================
@@ -6,6 +5,9 @@
:synopsis: Encode and decode files in uuencode format.
.. moduleauthor:: Lance Ellinghouse
+**Source code:** :source:`Lib/uu.py`
+
+--------------
This module encodes and decodes files in uuencode format, allowing arbitrary
binary data to be transferred over ASCII-only connections. Wherever a file
@@ -22,11 +24,6 @@
This code was contributed by Lance Ellinghouse, and modified by Jack Jansen.
-.. seealso::
-
- Latest version of the `uu module Python source code
- <http://svn.python.org/view/python/branches/release27-maint/Lib/uu.py?view=markup>`_
-
The :mod:`uu` module defines the following functions:
@@ -62,4 +59,3 @@
Module :mod:`binascii`
Support module containing ASCII-to-binary and binary-to-ASCII conversions.
-
diff --git a/Doc/library/warnings.rst b/Doc/library/warnings.rst
--- a/Doc/library/warnings.rst
+++ b/Doc/library/warnings.rst
@@ -9,6 +9,10 @@
.. versionadded:: 2.1
+**Source code:** :source:`Lib/warnings.py`
+
+--------------
+
Warning messages are typically issued in situations where it is useful to alert
the user of some condition in a program, where that condition (normally) doesn't
warrant raising an exception and terminating the program. For example, one
diff --git a/Doc/library/wave.rst b/Doc/library/wave.rst
--- a/Doc/library/wave.rst
+++ b/Doc/library/wave.rst
@@ -6,6 +6,10 @@
.. sectionauthor:: Moshe Zadka <moshez at zadka.site.co.il>
.. Documentations stolen from comments in file.
+**Source code:** :source:`Lib/wave.py`
+
+--------------
+
The :mod:`wave` module provides a convenient interface to the WAV sound format.
It does not support compression/decompression, but it does support mono/stereo.
diff --git a/Doc/library/weakref.rst b/Doc/library/weakref.rst
--- a/Doc/library/weakref.rst
+++ b/Doc/library/weakref.rst
@@ -11,6 +11,10 @@
.. versionadded:: 2.1
+**Source code:** :source:`Lib/weakref.py`
+
+--------------
+
The :mod:`weakref` module allows the Python programmer to create :dfn:`weak
references` to objects.
diff --git a/Doc/library/webbrowser.rst b/Doc/library/webbrowser.rst
--- a/Doc/library/webbrowser.rst
+++ b/Doc/library/webbrowser.rst
@@ -1,4 +1,3 @@
-
:mod:`webbrowser` --- Convenient Web-browser controller
=======================================================
@@ -7,6 +6,9 @@
.. moduleauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
.. sectionauthor:: Fred L. Drake, Jr. <fdrake at acm.org>
+**Source code:** :source:`Lib/webbrowser.py`
+
+--------------
The :mod:`webbrowser` module provides a high-level interface to allow displaying
Web-based documents to users. Under most circumstances, simply calling the
diff --git a/Doc/library/xdrlib.rst b/Doc/library/xdrlib.rst
--- a/Doc/library/xdrlib.rst
+++ b/Doc/library/xdrlib.rst
@@ -1,4 +1,3 @@
-
:mod:`xdrlib` --- Encode and decode XDR data
============================================
@@ -10,6 +9,10 @@
single: XDR
single: External Data Representation
+**Source code:** :source:`Lib/xdrlib.py`
+
+--------------
+
The :mod:`xdrlib` module supports the External Data Representation Standard as
described in :rfc:`1014`, written by Sun Microsystems, Inc. June 1987. It
supports most of the data types described in the RFC.
diff --git a/Doc/library/xml.dom.minidom.rst b/Doc/library/xml.dom.minidom.rst
--- a/Doc/library/xml.dom.minidom.rst
+++ b/Doc/library/xml.dom.minidom.rst
@@ -1,4 +1,3 @@
-
:mod:`xml.dom.minidom` --- Lightweight DOM implementation
=========================================================
@@ -11,6 +10,10 @@
.. versionadded:: 2.0
+**Source code:** :source:`Lib/xml/dom/minidom.py`
+
+--------------
+
:mod:`xml.dom.minidom` is a light-weight implementation of the Document Object
Model interface. It is intended to be simpler than the full DOM and also
significantly smaller.
diff --git a/Doc/library/xml.dom.pulldom.rst b/Doc/library/xml.dom.pulldom.rst
--- a/Doc/library/xml.dom.pulldom.rst
+++ b/Doc/library/xml.dom.pulldom.rst
@@ -1,4 +1,3 @@
-
:mod:`xml.dom.pulldom` --- Support for building partial DOM trees
=================================================================
@@ -9,6 +8,10 @@
.. versionadded:: 2.0
+**Source code:** :source:`Lib/xml/dom/pulldom.py`
+
+--------------
+
:mod:`xml.dom.pulldom` allows building only selected portions of a Document
Object Model representation of a document from SAX events.
diff --git a/Doc/library/xml.etree.elementtree.rst b/Doc/library/xml.etree.elementtree.rst
--- a/Doc/library/xml.etree.elementtree.rst
+++ b/Doc/library/xml.etree.elementtree.rst
@@ -1,4 +1,3 @@
-
:mod:`xml.etree.ElementTree` --- The ElementTree XML API
========================================================
@@ -9,6 +8,10 @@
.. versionadded:: 2.5
+**Source code:** :source:`Lib/xml/etree/ElementTree.py`
+
+--------------
+
The :class:`Element` type is a flexible container object, designed to store
hierarchical data structures in memory. The type can be described as a cross
between a list and a dictionary.
diff --git a/Doc/library/xmlrpclib.rst b/Doc/library/xmlrpclib.rst
--- a/Doc/library/xmlrpclib.rst
+++ b/Doc/library/xmlrpclib.rst
@@ -17,6 +17,10 @@
.. versionadded:: 2.2
+**Source code:** :source:`Lib/xmlrpclib.py`
+
+--------------
+
XML-RPC is a Remote Procedure Call method that uses XML passed via HTTP as a
transport. With it, a client can call methods with parameters on a remote
server (the server is named by a URI) and get back structured data. This module
diff --git a/Doc/library/zipfile.rst b/Doc/library/zipfile.rst
--- a/Doc/library/zipfile.rst
+++ b/Doc/library/zipfile.rst
@@ -1,4 +1,3 @@
-
:mod:`zipfile` --- Work with ZIP archives
=========================================
@@ -9,6 +8,10 @@
.. versionadded:: 1.6
+**Source code:** :source:`Lib/zipfile.py`
+
+--------------
+
The ZIP file format is a common archive and compression standard. This module
provides tools to create, read, write, append, and list a ZIP file. Any
advanced use of this module will require an understanding of the format, as
diff --git a/Doc/tools/sphinxext/pyspecific.py b/Doc/tools/sphinxext/pyspecific.py
--- a/Doc/tools/sphinxext/pyspecific.py
+++ b/Doc/tools/sphinxext/pyspecific.py
@@ -5,11 +5,12 @@
Sphinx extension with Python doc-specific markup.
- :copyright: 2008, 2009 by Georg Brandl.
+ :copyright: 2008-2011 by Georg Brandl.
:license: Python license.
"""
ISSUE_URI = 'http://bugs.python.org/issue%s'
+SOURCE_URI = 'http://hg.python.org/cpython/file/2.7/%s'
from docutils import nodes, utils
@@ -44,6 +45,14 @@
return [refnode], []
+# Support for linking to Python source files easily
+
+def source_role(typ, rawtext, text, lineno, inliner, options={}, content=[]):
+ path = utils.unescape(text)
+ refnode = nodes.reference(path, path, refuri=SOURCE_URI % path)
+ return [refnode], []
+
+
# Support for marking up implementation details
from sphinx.util.compat import Directive
@@ -168,6 +177,7 @@
def setup(app):
app.add_role('issue', issue_role)
+ app.add_role('source', source_role)
app.add_directive('impl-detail', ImplementationDetail)
app.add_builder(PydocTopicsBuilder)
app.add_builder(suspicious.CheckSuspiciousMarkupBuilder)
diff --git a/Doc/tutorial/interactive.rst b/Doc/tutorial/interactive.rst
--- a/Doc/tutorial/interactive.rst
+++ b/Doc/tutorial/interactive.rst
@@ -156,17 +156,18 @@
quotes, etc., would also be useful.
One alternative enhanced interactive interpreter that has been around for quite
-some time is `IPython`_, which features tab completion, object exploration and
+some time is IPython_, which features tab completion, object exploration and
advanced history management. It can also be thoroughly customized and embedded
into other applications. Another similar enhanced interactive environment is
-`bpython`_.
+bpython_.
.. rubric:: Footnotes
.. [#] Python will execute the contents of a file identified by the
:envvar:`PYTHONSTARTUP` environment variable when you start an interactive
- interpreter.
+ interpreter. To customize Python even for non-interactive mode, see
+ :ref:`tut-customize`.
.. _GNU Readline: http://tiswww.case.edu/php/chet/readline/rltop.html
diff --git a/Doc/tutorial/interpreter.rst b/Doc/tutorial/interpreter.rst
--- a/Doc/tutorial/interpreter.rst
+++ b/Doc/tutorial/interpreter.rst
@@ -242,7 +242,29 @@
execfile(filename)
+.. _tut-customize:
+
+The Customization Modules
+-------------------------
+
+Python provides two hooks to let you customize it: :mod:`sitecustomize` and
+:mod:`usercustomize`. To see how it works, you need first to find the location
+of your user site-packages directory. Start Python and run this code:
+
+ >>> import site
+ >>> site.getusersitepackages()
+ '/home/user/.local/lib/python3.2/site-packages'
+
+Now you can create a file named :file:`usercustomize.py` in that directory and
+put anything you want in it. It will affect every invocation of Python, unless
+it is started with the :option:`-s` option to disable the automatic import.
+
+:mod:`sitecustomize` works in the same way, but is typically created by an
+administrator of the computer in the global site-packages directory, and is
+imported before :mod:`usercustomize`. See the documentation of the :mod:`site`
+module for more details.
+
+
.. rubric:: Footnotes
.. [#] A problem with the GNU Readline package may prevent this.
-
diff --git a/Doc/using/cmdline.rst b/Doc/using/cmdline.rst
--- a/Doc/using/cmdline.rst
+++ b/Doc/using/cmdline.rst
@@ -255,7 +255,8 @@
.. cmdoption:: -s
- Don't add user site directory to sys.path
+ Don't add the :data:`user site-packages directory <site.USER_SITE>` to
+ :data:`sys.path`.
.. versionadded:: 2.6
@@ -532,7 +533,8 @@
.. envvar:: PYTHONNOUSERSITE
- If this is set, Python won't add the user site directory to sys.path
+ If this is set, Python won't add the :data:`user site-packages directory
+ <site.USER_SITE>` to :data:`sys.path`.
.. versionadded:: 2.6
@@ -543,7 +545,10 @@
.. envvar:: PYTHONUSERBASE
- Sets the base directory for the user site directory
+ Defines the :data:`user base directory <site.USER_BASE>`, which is used to
+ compute the path of the :data:`user site-packages directory <site.USER_SITE>`
+ and :ref:`Distutils installation paths <inst-alt-install-user>` for ``python
+ setup.py install --user``.
.. versionadded:: 2.6
diff --git a/Lib/shutil.py b/Lib/shutil.py
--- a/Lib/shutil.py
+++ b/Lib/shutil.py
@@ -359,7 +359,8 @@
archive_dir = os.path.dirname(archive_name)
if not os.path.exists(archive_dir):
- logger.info("creating %s" % archive_dir)
+ if logger is not None:
+ logger.info("creating %s", archive_dir)
if not dry_run:
os.makedirs(archive_dir)
diff --git a/Lib/test/test_shutil.py b/Lib/test/test_shutil.py
--- a/Lib/test/test_shutil.py
+++ b/Lib/test/test_shutil.py
@@ -349,6 +349,8 @@
self.write_file([tmpdir, 'sub', 'file3'], 'xxx')
tmpdir2 = self.mkdtemp()
+ # force shutil to create the directory
+ os.rmdir(tmpdir2)
unittest.skipUnless(splitdrive(tmpdir)[0] == splitdrive(tmpdir2)[0],
"source and target should be on same drive")
@@ -464,6 +466,8 @@
self.write_file([tmpdir, 'file2'], 'xxx')
tmpdir2 = self.mkdtemp()
+ # force shutil to create the directory
+ os.rmdir(tmpdir2)
base_name = os.path.join(tmpdir2, 'archive')
_make_zipfile(base_name, tmpdir)
diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -1222,7 +1222,7 @@
# Find files with funny names
funny:
- find $(DISTDIRS) -type d \
+ find $(SUBDIRS) $(SUBDIRSTOO) -type d \
-o -name '*.[chs]' \
-o -name '*.py' \
-o -name '*.doc' \
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -40,6 +40,8 @@
Library
-------
+- Issue #9173: Let shutil._make_archive work if the logger argument is None.
+
- Issue #12650: Fix a race condition where a subprocess.Popen could leak
resources (FD/zombie) when killed at the wrong time.
diff --git a/Tools/scripts/patchcheck.py b/Tools/scripts/patchcheck.py
--- a/Tools/scripts/patchcheck.py
+++ b/Tools/scripts/patchcheck.py
@@ -157,8 +157,9 @@
reported_news(special_files)
# Test suite run and passed.
- print
- print "Did you run the test suite?"
+ if python_files or c_files:
+ print
+ print "Did you run the test suite?"
if __name__ == '__main__':
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list