Move the 3k reST doc tree in place.

Doc/ACKS.txt

+Contributors to the Python Documentation
+----------------------------------------
+
+This file lists people who have contributed in some way to the Python
+documentation.  It is probably not complete -- if you feel that you or
+anyone else should be on this list, please let us know (send email to
+docs@python.org), and we'll be glad to correct the problem.
+
+* Aahz
+* Michael Abbott
+* Steve Alexander
+* Jim Ahlstrom
+* Fred Allen
+* A. Amoroso
+* Pehr Anderson
+* Oliver Andrich
+* Jesús Cea Avión
+* Daniel Barclay
+* Chris Barker
+* Don Bashford
+* Anthony Baxter
+* Bennett Benson
+* Jonathan Black
+* Robin Boerdijk
+* Michal Bozon
+* Aaron Brancotti
+* Georg Brandl
+* Keith Briggs
+* Lee Busby
+* Lorenzo M. Catucci
+* Carl Cerecke
+* Mauro Cicognini
+* Gilles Civario
+* Mike Clarkson
+* Steve Clift
+* Dave Cole
+* Matthew Cowles
+* Jeremy Craven
+* Andrew Dalke
+* Ben Darnell
+* L. Peter Deutsch
+* Robert Donohue
+* Fred L. Drake, Jr.
+* Jeff Epler
+* Michael Ernst
+* Blame Andy Eskilsson
+* Carey Evans
+* Martijn Faassen
+* Carl Feynman
+* Hernán Martínez Foffani
+* Stefan Franke
+* Jim Fulton
+* Peter Funk
+* Lele Gaifax
+* Matthew Gallagher
+* Ben Gertzfield
+* Nadim Ghaznavi
+* Jonathan Giddy
+* Shelley Gooch
+* Nathaniel Gray
+* Grant Griffin
+* Thomas Guettler
+* Anders Hammarquist
+* Mark Hammond
+* Harald Hanche-Olsen
+* Manus Hand
+* Gerhard Häring
+* Travis B. Hartwell
+* Tim Hatch
+* Janko Hauser
+* Bernhard Herzog
+* Magnus L. Hetland
+* Konrad Hinsen
+* Stefan Hoffmeister
+* Albert Hofkamp
+* Gregor Hoffleit
+* Steve Holden
+* Thomas Holenstein
+* Gerrit Holl
+* Rob Hooft
+* Brian Hooper
+* Randall Hopper
+* Michael Hudson
+* Eric Huss
+* Jeremy Hylton
+* Roger Irwin
+* Jack Jansen
+* Philip H. Jensen
+* Pedro Diaz Jimenez
+* Kent Johnson
+* Lucas de Jonge
+* Andreas Jung
+* Robert Kern
+* Jim Kerr
+* Jan Kim
+* Greg Kochanski
+* Guido Kollerie
+* Peter A. Koren
+* Daniel Kozan
+* Andrew M. Kuchling
+* Dave Kuhlman
+* Erno Kuusela
+* Detlef Lannert
+* Piers Lauder
+* Glyph Lefkowitz
+* Marc-André Lemburg
+* Ulf A. Lindgren
+* Everett Lipman
+* Mirko Liss
+* Martin von Löwis
+* Fredrik Lundh
+* Jeff MacDonald
+* John Machin
+* Andrew MacIntyre
+* Vladimir Marangozov
+* Vincent Marchetti
+* Laura Matson
+* Daniel May
+* Doug Mennella
+* Paolo Milani
+* Skip Montanaro
+* Paul Moore
+* Ross Moore
+* Sjoerd Mullender
+* Dale Nagata
+* Ng Pheng Siong
+* Koray Oner
+* Tomas Oppelstrup
+* Denis S. Otkidach
+* Zooko O'Whielacronx
+* William Park
+* Joonas Paalasmaa
+* Harri Pasanen
+* Bo Peng
+* Tim Peters
+* Christopher Petrilli
+* Justin D. Pettit
+* Chris Phoenix
+* François Pinard
+* Paul Prescod
+* Eric S. Raymond
+* Edward K. Ream
+* Sean Reifschneider
+* Bernhard Reiter
+* Armin Rigo
+* Wes Rishel
+* Jim Roskind
+* Guido van Rossum
+* Donald Wallace Rouse II
+* Nick Russo
+* Chris Ryland
+* Constantina S.
+* Hugh Sasse
+* Bob Savage
+* Scott Schram
+* Neil Schemenauer
+* Barry Scott
+* Joakim Sernbrant
+* Justin Sheehy
+* Michael Simcich
+* Ionel Simionescu
+* Gregory P. Smith
+* Roy Smith
+* Clay Spence
+* Nicholas Spies
+* Tage Stabell-Kulo
+* Frank Stajano
+* Anthony Starks
+* Greg Stein
+* Peter Stoehr
+* Mark Summerfield
+* Reuben Sumner
+* Kalle Svensson
+* Jim Tittsler
+* Ville Vainio
+* Martijn Vries
+* Charles G. Waldman
+* Greg Ward
+* Barry Warsaw
+* Corran Webster
+* Glyn Webster
+* Bob Weiner
+* Eddy Welbourne
+* Mats Wichmann
+* Gerry Wiener
+* Timothy Wild
+* Collin Winter
+* Blake Winton
+* Dan Wolfe
+* Steven Work
+* Thomas Wouters
+* Ka-Ping Yee
+* Rory Yorke
+* Moshe Zadka
+* Milan Zamazal
+* Cheng Zhang

Doc/Makefile

+#
+# Makefile for Python documentation
+# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+#
+
+# You can set these variables from the command line.
+PYTHON       ?= python
+SVNROOT      ?= http://svn.python.org/projects
+SPHINXOPTS   ?=
+
+ALLSPHINXOPTS = -b$(BUILDER) -dbuild/doctrees $(SPHINXOPTS) . build/$(BUILDER)
+
+.PHONY: help checkout update build html web htmlhelp clean
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html  to make standalone HTML files"
+	@echo "  web   to make file usable by Sphinx.web"
+	@echo "  htmlhelp to make HTML files and a HTML help project"
+
+checkout:
+	@if [ ! -d tools/sphinx ]; then \
+	  echo "Checking out Sphinx..."; \
+	  svn checkout $(SVNROOT)/doctools/trunk/sphinx tools/sphinx; \
+	fi
+	@if [ ! -d tools/docutils ]; then \
+	  echo "Checking out Docutils..."; \
+	  svn checkout $(SVNROOT)/external/docutils-0.4/docutils tools/docutils; \
+	fi
+	@if [ ! -d tools/pygments ]; then \
+	  echo "Checking out Pygments..."; \
+	  svn checkout $(SVNROOT)/external/Pygments-0.8.1/pygments tools/pygments; \
+	fi
+
+update:
+	svn update tools/sphinx
+	svn update tools/docutils
+	svn update tools/pygments
+
+build: checkout
+	mkdir -p build/$(BUILDER) build/doctrees
+	$(PYTHON) tools/sphinx-build.py $(ALLSPHINXOPTS)
+	@echo
+
+html: BUILDER = html
+html: build
+	@echo "Build finished. The HTML pages are in build/html."
+
+web: BUILDER = web
+web: build
+	@echo "Build finished; now you can run"
+	@echo "  PYTHONPATH=tools $(PYTHON) -m sphinx.web build/web"
+	@echo "to start the server."
+
+htmlhelp: BUILDER = htmlhelp
+htmlhelp: build
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      "build/hhp/pydoc.hhp project file."
+
+clean:
+	-rm -rf build/*
+	-rm -rf tools/sphinx

Doc/README.txt

+Python Documentation README
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This directory contains the reStructuredText (reST) sources to the Python
+documentation.  You don't need to build them yourself, prebuilt versions are
+available at http://docs.python.org/download/.
+
+Documentation on the authoring Python documentation, including information about
+both style and markup, is available in the "Documenting Python" chapter of the
+documentation.  There's also a chapter intended to point out differences to
+those familiar with the previous docs written in LaTeX.
+
+
+Building the docs
+=================
+
+You need to install Python 2.5 or higher; the toolset used to build the docs are
+written in Python.  The toolset used to build the documentation is called
+*Sphinx*, it is not included in this tree, but maintained separately in the
+Python Subversion repository.  Also needed are Jinja, a templating engine
+(included in Sphinx as a Subversion external), and optionally Pygments, a code
+highlighter.
+
+
+Using make
+----------
+
+Luckily, a Makefile has been prepared so that on Unix, provided you have
+installed Python and Subversion, you can just run ::
+
+   make html
+
+to check out the necessary toolset in the `tools/` subdirectory and build the
+HTML output files.  To view the generated HTML, point your favorite browser at
+the top-level index `build/html/index.html` after running "make".
+
+Available make targets are:
+
+ * "html", which builds standalone HTML files for offline viewing.
+
+ * "web", which builds files usable with the Sphinx.web application (used to
+   serve the docs online at http://docs.python.org/).
+
+ * "htmlhelp", which builds HTML files and a HTML Help project file usable to
+   convert them into a single Compiled HTML (.chm) file -- these are popular
+   under Microsoft Windows, but very handy on every platform.
+
+   To create the CHM file, you need to run the Microsoft HTML Help Workshop
+   over the generated project (.hhp) file.
+
+A "make update" updates the Subversion checkouts in `tools/`.
+
+
+Without make
+------------
+
+You'll need to checkout the Sphinx package to the `tools/` directory::
+
+   svn co http://svn.python.org/projects/doctools/trunk/sphinx tools/sphinx
+
+Then, you need to install Docutils 0.4 (the SVN snapshot won't work), either
+by checking it out via ::
+
+   svn co http://svn.python.org/projects/external/docutils-0.4/docutils tools/docutils
+
+or by installing it from http://docutils.sf.net/.
+
+You can optionally also install Pygments, either as a checkout via :: 
+
+   svn co http://svn.python.org/projects/external/Pygments-0.8.1/pygments tools/pygments
+
+or from PyPI at http://pypi.python.org/pypi/Pygments.
+
+
+Then, make an output directory, e.g. under `build/`, and run ::
+
+   python tools/sphinx-build.py -b<builder> . build/<outputdirectory>
+
+where `<builder>` is one of html, web or htmlhelp (for explanations see the make
+targets above).
+
+
+Contributing
+============
+
+For bugs in the content, the online version at http://docs.python.org/ has a
+"suggest change" facility that can be used to correct errors in the source text
+and submit them as a patch to the maintainers.
+
+Bugs in the toolset should be reported in the Python bug tracker at
+http://bugs.python.org/.
+
+You can also send a mail to the Python Documentation Team at docs@python.org,
+and we will process your request as soon as possible.
+
+If you want to help the Documentation Team, you are always welcome.  Just send
+a mail to docs@python.org.
+
+
+Copyright notice
+================
+
+The Python source is copyrighted, but you can freely use and copy it
+as long as you don't change or remove the copyright notice:
+
+----------------------------------------------------------------------
+Copyright (c) 2000-2007 Python Software Foundation.
+All rights reserved.
+
+Copyright (c) 2000 BeOpen.com.
+All rights reserved.
+
+Copyright (c) 1995-2000 Corporation for National Research Initiatives.
+All rights reserved.
+
+Copyright (c) 1991-1995 Stichting Mathematisch Centrum.
+All rights reserved.
+
+See the file "license.rst" for information on usage and redistribution
+of this file, and for a DISCLAIMER OF ALL WARRANTIES.
+----------------------------------------------------------------------

Doc/TODO.txt

+To do
+=====
+
+* split very large files and add toctrees
+* finish "Documenting Python"
+* care about XXX comments

Doc/about.rst

+=====================
+About these documents
+=====================
+
+
+These documents are generated from `reStructuredText
+<http://docutils.sf.net/rst.html>`_ sources by *Sphinx*, a document processor
+specifically written for the Python documentation.
+
+In the online version of these documents, you can submit comments and suggest
+changes directly on the documentation pages.
+
+Development of the documentation and its toolchain takes place on the
+docs@python.org mailing list.  We're always looking for volunteers wanting
+to help with the docs, so feel free to send a mail there!
+
+Many thanks go to:
+
+* Fred L. Drake, Jr., the creator of the original Python documentation toolset
+  and writer of much of the content;
+* the `docutils <http://docutils.sf.net/>`_ project for creating
+  reStructuredText and the docutils suite;
+* Fredrik Lundh for his `Alternative Python Reference
+  <http://effbot.org/zone/pyref.htm>`_ project from which Sphinx got many good
+  ideas.
+
+See :ref:`reporting-bugs` for information how to report bugs in Python itself.
+
+.. including the ACKS file here so that it can be maintained separately
+.. include:: ACKS.txt
+
+It is only with the input and contributions of the Python community
+that Python has such wonderful documentation -- Thank You!

Doc/bugs.rst

+.. _reporting-bugs:
+
+************************
+Reporting Bugs in Python
+************************
+
+Python is a mature programming language which has established a reputation for
+stability.  In order to maintain this reputation, the developers would like to
+know of any deficiencies you find in Python.
+
+If you find errors in the documentation, please use either the "Add a comment"
+or the "Suggest a change" features of the relevant page in the most recent
+online documentation at http://docs.python.org/.
+
+All other bug reports should be submitted via the Python Bug Tracker
+(http://bugs.python.org/).  The bug tracker offers a Web form which allows
+pertinent information to be entered and submitted to the developers.
+
+The first step in filing a report is to determine whether the problem has
+already been reported.  The advantage in doing so, aside from saving the
+developers time, is that you learn what has been done to fix it; it may be that
+the problem has already been fixed for the next release, or additional
+information is needed (in which case you are welcome to provide it if you can!).
+To do this, search the bug database using the search box on the top of the page.
+
+If the problem you're reporting is not already in the bug tracker, go back to
+the Python Bug Tracker.  If you don't already have a tracker account, select the
+"Register" link in the sidebar and undergo the registration procedure.
+Otherwise, if you're not logged in, enter your credentials and select "Login".
+It is not possible to submit a bug report anonymously.
+
+Being now logged in, you can submit a bug.  Select the "Create New" link in the
+sidebar to open the bug reporting form.
+
+The submission form has a number of fields.  For the "Title" field, enter a
+*very* short description of the problem; less than ten words is good.  In the
+"Type" field, select the type of your problem; also select the "Component" and
+"Versions" to which the bug relates.
+
+In the "Change Note" field, describe the problem in detail, including what you
+expected to happen and what did happen.  Be sure to include whether any
+extension modules were involved, and what hardware and software platform you
+were using (including version information as appropriate).
+
+Each bug report will be assigned to a developer who will determine what needs to
+be done to correct the problem.  You will receive an update each time action is
+taken on the bug.
+
+
+.. seealso::
+
+   `How to Report Bugs Effectively <http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation/ReportingBugs.html>`_
+      Article which goes into some detail about how to create a useful bug report.
+      This describes what kind of information is useful and why it is useful.
+
+   `Bug Writing Guidelines <http://www.mozilla.org/quality/bug-writing-guidelines.html>`_
+      Information about writing a good bug report.  Some of this is specific to the
+      Mozilla project, but describes general good practices.
+

Doc/c-api/index.rst

+.. _c-api-index:
+
+##################################
+  Python/C API Reference Manual
+##################################
+
+:Release: |version|
+:Date: |today|
+
+This manual documents the API used by C and C++ programmers who want to write
+extension modules or embed Python.  It is a companion to :ref:`extending-index`,
+which describes the general principles of extension writing but does not
+document the API functions in detail.
+
+.. warning::
+
+   The current version of this document is somewhat incomplete. However, most of
+   the important functions, types and structures are described.
+
+
+.. toctree::
+   :maxdepth: 2
+
+   intro.rst
+   veryhigh.rst
+   refcounting.rst
+   exceptions.rst
+   utilities.rst
+   abstract.rst
+   concrete.rst
+   init.rst
+   memory.rst
+   newtypes.rst

Doc/c-api/memory.rst

+.. highlightlang:: c
+
+
+.. _memory:
+
+*****************
+Memory Management
+*****************
+
+.. sectionauthor:: Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr>
+
+
+
+.. _memoryoverview:
+
+Overview
+========
+
+Memory management in Python involves a private heap containing all Python
+objects and data structures. The management of this private heap is ensured
+internally by the *Python memory manager*.  The Python memory manager has
+different components which deal with various dynamic storage management aspects,
+like sharing, segmentation, preallocation or caching.
+
+At the lowest level, a raw memory allocator ensures that there is enough room in
+the private heap for storing all Python-related data by interacting with the
+memory manager of the operating system. On top of the raw memory allocator,
+several object-specific allocators operate on the same heap and implement
+distinct memory management policies adapted to the peculiarities of every object
+type. For example, integer objects are managed differently within the heap than
+strings, tuples or dictionaries because integers imply different storage
+requirements and speed/space tradeoffs. The Python memory manager thus delegates
+some of the work to the object-specific allocators, but ensures that the latter
+operate within the bounds of the private heap.
+
+It is important to understand that the management of the Python heap is
+performed by the interpreter itself and that the user has no control over it,
+even if she regularly manipulates object pointers to memory blocks inside that
+heap.  The allocation of heap space for Python objects and other internal
+buffers is performed on demand by the Python memory manager through the Python/C
+API functions listed in this document.
+
+.. index::
+   single: malloc()
+   single: calloc()
+   single: realloc()
+   single: free()
+
+To avoid memory corruption, extension writers should never try to operate on
+Python objects with the functions exported by the C library: :cfunc:`malloc`,
+:cfunc:`calloc`, :cfunc:`realloc` and :cfunc:`free`.  This will result in  mixed
+calls between the C allocator and the Python memory manager with fatal
+consequences, because they implement different algorithms and operate on
+different heaps.  However, one may safely allocate and release memory blocks
+with the C library allocator for individual purposes, as shown in the following
+example::
+
+   PyObject *res;
+   char *buf = (char *) malloc(BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   ...Do some I/O operation involving buf...
+   res = PyString_FromString(buf);
+   free(buf); /* malloc'ed */
+   return res;
+
+In this example, the memory request for the I/O buffer is handled by the C
+library allocator. The Python memory manager is involved only in the allocation
+of the string object returned as a result.
+
+In most situations, however, it is recommended to allocate memory from the
+Python heap specifically because the latter is under control of the Python
+memory manager. For example, this is required when the interpreter is extended
+with new object types written in C. Another reason for using the Python heap is
+the desire to *inform* the Python memory manager about the memory needs of the
+extension module. Even when the requested memory is used exclusively for
+internal, highly-specific purposes, delegating all memory requests to the Python
+memory manager causes the interpreter to have a more accurate image of its
+memory footprint as a whole. Consequently, under certain circumstances, the
+Python memory manager may or may not trigger appropriate actions, like garbage
+collection, memory compaction or other preventive procedures. Note that by using
+the C library allocator as shown in the previous example, the allocated memory
+for the I/O buffer escapes completely the Python memory manager.
+
+
+.. _memoryinterface:
+
+Memory Interface
+================
+
+The following function sets, modeled after the ANSI C standard, but specifying
+behavior when requesting zero bytes, are available for allocating and releasing
+memory from the Python heap:
+
+
+.. cfunction:: void* PyMem_Malloc(size_t n)
+
+   Allocates *n* bytes and returns a pointer of type :ctype:`void\*` to the
+   allocated memory, or *NULL* if the request fails. Requesting zero bytes returns
+   a distinct non-*NULL* pointer if possible, as if :cfunc:`PyMem_Malloc(1)` had
+   been called instead. The memory will not have been initialized in any way.
+
+
+.. cfunction:: void* PyMem_Realloc(void *p, size_t n)
+
+   Resizes the memory block pointed to by *p* to *n* bytes. The contents will be
+   unchanged to the minimum of the old and the new sizes. If *p* is *NULL*, the
+   call is equivalent to :cfunc:`PyMem_Malloc(n)`; else if *n* is equal to zero,
+   the memory block is resized but is not freed, and the returned pointer is
+   non-*NULL*.  Unless *p* is *NULL*, it must have been returned by a previous call
+   to :cfunc:`PyMem_Malloc` or :cfunc:`PyMem_Realloc`. If the request fails,
+   :cfunc:`PyMem_Realloc` returns *NULL* and *p* remains a valid pointer to the
+   previous memory area.
+
+
+.. cfunction:: void PyMem_Free(void *p)
+
+   Frees the memory block pointed to by *p*, which must have been returned by a
+   previous call to :cfunc:`PyMem_Malloc` or :cfunc:`PyMem_Realloc`.  Otherwise, or
+   if :cfunc:`PyMem_Free(p)` has been called before, undefined behavior occurs. If
+   *p* is *NULL*, no operation is performed.
+
+The following type-oriented macros are provided for convenience.  Note  that
+*TYPE* refers to any C type.
+
+
+.. cfunction:: TYPE* PyMem_New(TYPE, size_t n)
+
+   Same as :cfunc:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes of
+   memory.  Returns a pointer cast to :ctype:`TYPE\*`.  The memory will not have
+   been initialized in any way.
+
+
+.. cfunction:: TYPE* PyMem_Resize(void *p, TYPE, size_t n)
+
+   Same as :cfunc:`PyMem_Realloc`, but the memory block is resized to ``(n *
+   sizeof(TYPE))`` bytes.  Returns a pointer cast to :ctype:`TYPE\*`. On return,
+   *p* will be a pointer to the new memory area, or *NULL* in the event of failure.
+
+
+.. cfunction:: void PyMem_Del(void *p)
+
+   Same as :cfunc:`PyMem_Free`.
+
+In addition, the following macro sets are provided for calling the Python memory
+allocator directly, without involving the C API functions listed above. However,
+note that their use does not preserve binary compatibility across Python
+versions and is therefore deprecated in extension modules.
+
+:cfunc:`PyMem_MALLOC`, :cfunc:`PyMem_REALLOC`, :cfunc:`PyMem_FREE`.
+
+:cfunc:`PyMem_NEW`, :cfunc:`PyMem_RESIZE`, :cfunc:`PyMem_DEL`.
+
+
+.. _memoryexamples:
+
+Examples
+========
+
+Here is the example from section :ref:`memoryoverview`, rewritten so that the
+I/O buffer is allocated from the Python heap by using the first function set::
+
+   PyObject *res;
+   char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   /* ...Do some I/O operation involving buf... */
+   res = PyString_FromString(buf);
+   PyMem_Free(buf); /* allocated with PyMem_Malloc */
+   return res;
+
+The same code using the type-oriented function set::
+
+   PyObject *res;
+   char *buf = PyMem_New(char, BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   /* ...Do some I/O operation involving buf... */
+   res = PyString_FromString(buf);
+   PyMem_Del(buf); /* allocated with PyMem_New */
+   return res;
+
+Note that in the two examples above, the buffer is always manipulated via
+functions belonging to the same set. Indeed, it is required to use the same
+memory API family for a given memory block, so that the risk of mixing different
+allocators is reduced to a minimum. The following code sequence contains two
+errors, one of which is labeled as *fatal* because it mixes two different
+allocators operating on different heaps. ::
+
+   char *buf1 = PyMem_New(char, BUFSIZ);
+   char *buf2 = (char *) malloc(BUFSIZ);
+   char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
+   ...
+   PyMem_Del(buf3);  /* Wrong -- should be PyMem_Free() */
+   free(buf2);       /* Right -- allocated via malloc() */
+   free(buf1);       /* Fatal -- should be PyMem_Del()  */
+
+In addition to the functions aimed at handling raw memory blocks from the Python
+heap, objects in Python are allocated and released with :cfunc:`PyObject_New`,
+:cfunc:`PyObject_NewVar` and :cfunc:`PyObject_Del`.
+
+These will be explained in the next chapter on defining and implementing new
+object types in C.
+

Doc/c-api/refcounting.rst

+.. highlightlang:: c
+
+
+.. _countingrefs:
+
+******************
+Reference Counting
+******************
+
+The macros in this section are used for managing reference counts of Python
+objects.
+
+
+.. cfunction:: void Py_INCREF(PyObject *o)
+
+   Increment the reference count for object *o*.  The object must not be *NULL*; if
+   you aren't sure that it isn't *NULL*, use :cfunc:`Py_XINCREF`.
+
+
+.. cfunction:: void Py_XINCREF(PyObject *o)
+
+   Increment the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect.
+
+
+.. cfunction:: void Py_DECREF(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object must not be *NULL*; if
+   you aren't sure that it isn't *NULL*, use :cfunc:`Py_XDECREF`.  If the reference
+   count reaches zero, the object's type's deallocation function (which must not be
+   *NULL*) is invoked.
+
+   .. warning::
+
+      The deallocation function can cause arbitrary Python code to be invoked (e.g.
+      when a class instance with a :meth:`__del__` method is deallocated).  While
+      exceptions in such code are not propagated, the executed code has free access to
+      all Python global variables.  This means that any object that is reachable from
+      a global variable should be in a consistent state before :cfunc:`Py_DECREF` is
+      invoked.  For example, code to delete an object from a list should copy a
+      reference to the deleted object in a temporary variable, update the list data
+      structure, and then call :cfunc:`Py_DECREF` for the temporary variable.
+
+
+.. cfunction:: void Py_XDECREF(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect; otherwise the effect is the same as for
+   :cfunc:`Py_DECREF`, and the same warning applies.
+
+
+.. cfunction:: void Py_CLEAR(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect; otherwise the effect is the same as for
+   :cfunc:`Py_DECREF`, except that the argument is also set to *NULL*.  The warning
+   for :cfunc:`Py_DECREF` does not apply with respect to the object passed because
+   the macro carefully uses a temporary variable and sets the argument to *NULL*
+   before decrementing its reference count.
+
+   It is a good idea to use this macro whenever decrementing the value of a
+   variable that might be traversed during garbage collection.
+
+   .. versionadded:: 2.4
+
+The following functions are for runtime dynamic embedding of Python:
+``Py_IncRef(PyObject \*o)``, `Py_DecRef(PyObject \*o)``. They are
+simply exported function versions of :cfunc:`Py_XINCREF` and
+:cfunc:`Py_XDECREF`, respectively.
+
+The following functions or macros are only for use within the interpreter core:
+:cfunc:`_Py_Dealloc`, :cfunc:`_Py_ForgetReference`, :cfunc:`_Py_NewReference`,
+as well as the global variable :cdata:`_Py_RefTotal`.
+

Doc/conf.py

+# -*- coding: utf-8 -*-
+#
+# Python documentation build configuration file
+#
+# The contents of this file are pickled, so don't put values in the namespace
+# that aren't pickleable (module imports are okay, they're removed automatically).
+#
+
+# The default replacements for |version| and |release|.
+# If 'auto', Sphinx looks for the Include/patchlevel.h file in the current Python
+# source tree and replaces the values accordingly.
+#
+# The short X.Y version.
+# version = '2.6'
+version = 'auto'
+# The full version, including alpha/beta/rc tags.
+# release = '2.6a0'
+release = 'auto'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+today = ''
+# Else, today_fmt is used as the format for a strftime call.
+today_fmt = '%B %d, %Y'
+
+# The base URL for download links.
+download_base_url = 'http://docs.python.org/ftp/python/doc/'
+
+# List of files that shouldn't be included in the build.
+unused_files = [
+    'whatsnew/2.0.rst',
+    'whatsnew/2.1.rst',
+    'whatsnew/2.2.rst',
+    'whatsnew/2.3.rst',
+    'whatsnew/2.4.rst',
+    'whatsnew/2.5.rst',
+    'whatsnew/2.6.rst',
+    'maclib/scrap.rst',
+    'library/xmllib.rst',
+    'library/xml.etree.rst',
+]
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+last_updated_format = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+use_smartypants = True
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+add_module_names = True

Doc/contents.rst

+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ Python Documentation contents
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. toctree::
+
+   whatsnew/3.0.rst
+   tutorial/index.rst
+   reference/index.rst
+   library/index.rst
+   extending/index.rst
+   c-api/index.rst
+   distutils/index.rst
+   install/index.rst
+   documenting/index.rst
+   howto/index.rst
+
+   about.rst
+   bugs.rst
+   copyright.rst
+   license.rst

Doc/copyright.rst

+*********
+Copyright
+*********
+
+Python and this documentation is:
+
+Copyright © 2001-2007 Python Software Foundation. All rights reserved.
+
+Copyright © 2000 BeOpen.com. All rights reserved.
+
+Copyright © 1995-2000 Corporation for National Research Initiatives. All rights
+reserved.
+
+Copyright © 1991-1995 Stichting Mathematisch Centrum. All rights reserved.
+
+-------
+
+See :ref:`history-and-license` for complete license and permissions information.
+

Doc/includes/sqlite3/connect_db_1.py

+import sqlite3
+
+con = sqlite3.connect("mydb")