diff options
author | Benjamin Peterson <benjamin@python.org> | 2008-10-04 22:00:42 (GMT) |
---|---|---|
committer | Benjamin Peterson <benjamin@python.org> | 2008-10-04 22:00:42 (GMT) |
commit | e5384b08861edde56d0b280f5993766d309ab4d0 (patch) | |
tree | eb00d3d112d67d3300bbf23dec974c6994be07ea /Doc | |
parent | 7d8d9a588c497c627b62bd7fa79bc6fef693aa5f (diff) | |
download | cpython-e5384b08861edde56d0b280f5993766d309ab4d0.zip cpython-e5384b08861edde56d0b280f5993766d309ab4d0.tar.gz cpython-e5384b08861edde56d0b280f5993766d309ab4d0.tar.bz2 |
Merged revisions 66670,66681,66688,66696-66699 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r66670 | georg.brandl | 2008-09-28 15:01:36 -0500 (Sun, 28 Sep 2008) | 2 lines
Don't show version in title.
........
r66681 | georg.brandl | 2008-09-29 11:51:35 -0500 (Mon, 29 Sep 2008) | 2 lines
Update nasm location.
........
r66688 | jesse.noller | 2008-09-29 19:15:45 -0500 (Mon, 29 Sep 2008) | 2 lines
issue3770: if SEM_OPEN is 0, disable the mp.synchronize module, rev. Nick Coghlan, Damien Miller
........
r66696 | andrew.kuchling | 2008-09-30 07:31:07 -0500 (Tue, 30 Sep 2008) | 1 line
Edits, and add markup
........
r66697 | andrew.kuchling | 2008-09-30 08:00:34 -0500 (Tue, 30 Sep 2008) | 1 line
Markup fix
........
r66698 | andrew.kuchling | 2008-09-30 08:00:51 -0500 (Tue, 30 Sep 2008) | 1 line
Markup fixes
........
r66699 | andrew.kuchling | 2008-09-30 08:01:46 -0500 (Tue, 30 Sep 2008) | 1 line
Markup fixes. (optparse.rst probably needs an entire revision pass.)
........
Diffstat (limited to 'Doc')
-rw-r--r-- | Doc/c-api/number.rst | 2 | ||||
-rw-r--r-- | Doc/c-api/object.rst | 2 | ||||
-rw-r--r-- | Doc/howto/urllib2.rst | 23 | ||||
-rw-r--r-- | Doc/library/ctypes.rst | 2 | ||||
-rw-r--r-- | Doc/library/multiprocessing.rst | 7 | ||||
-rw-r--r-- | Doc/library/optparse.rst | 28 | ||||
-rw-r--r-- | Doc/library/subprocess.rst | 2 | ||||
-rw-r--r-- | Doc/tools/sphinxext/download.html | 5 |
8 files changed, 40 insertions, 31 deletions
diff --git a/Doc/c-api/number.rst b/Doc/c-api/number.rst index 1bf08ad..bb72119 100644 --- a/Doc/c-api/number.rst +++ b/Doc/c-api/number.rst @@ -256,7 +256,7 @@ Number Protocol .. cfunction:: PyObject* PyNumber_Index(PyObject *o) Returns the *o* converted to a Python int or long on success or *NULL* with a - TypeError exception raised on failure. + :exc:`TypeError` exception raised on failure. .. cfunction:: PyObject* PyNumber_ToBase(PyObject *n, int base) diff --git a/Doc/c-api/object.rst b/Doc/c-api/object.rst index 7b9682c..bf2f484 100644 --- a/Doc/c-api/object.rst +++ b/Doc/c-api/object.rst @@ -257,7 +257,7 @@ is considered sufficient for this determination. .. cfunction:: long PyObject_HashNotImplemented(PyObject *o) - Set a TypeError indicating that ``type(o)`` is not hashable and return ``-1``. + Set a :exc:`TypeError` indicating that ``type(o)`` is not hashable and return ``-1``. This function receives special treatment when stored in a ``tp_hash`` slot, allowing a type to explicitly indicate to the interpreter that it is not hashable. diff --git a/Doc/howto/urllib2.rst b/Doc/howto/urllib2.rst index 5d32d4a..d74729b 100644 --- a/Doc/howto/urllib2.rst +++ b/Doc/howto/urllib2.rst @@ -182,11 +182,12 @@ which comes after we have a look at what happens when things go wrong. Handling Exceptions =================== -*urlopen* raises ``URLError`` when it cannot handle a response (though as usual -with Python APIs, builtin exceptions such as ValueError, TypeError etc. may also +*urlopen* raises :exc:`URLError` when it cannot handle a response (though as usual +with Python APIs, builtin exceptions such as +:exc:`ValueError`, :exc:`TypeError` etc. may also be raised). -``HTTPError`` is the subclass of ``URLError`` raised in the specific case of +:exc:`HTTPError` is the subclass of :exc:`URLError` raised in the specific case of HTTP URLs. The exception classes are exported from the :mod:`urllib.error` module. @@ -217,12 +218,12 @@ the status code indicates that the server is unable to fulfil the request. The default handlers will handle some of these responses for you (for example, if the response is a "redirection" that requests the client fetch the document from a different URL, urllib will handle that for you). For those it can't handle, -urlopen will raise an ``HTTPError``. Typical errors include '404' (page not +urlopen will raise an :exc:`HTTPError`. Typical errors include '404' (page not found), '403' (request forbidden), and '401' (authentication required). See section 10 of RFC 2616 for a reference on all the HTTP error codes. -The ``HTTPError`` instance raised will have an integer 'code' attribute, which +The :exc:`HTTPError` instance raised will have an integer 'code' attribute, which corresponds to the error sent by the server. Error Codes @@ -305,7 +306,7 @@ dictionary is reproduced here for convenience :: } When an error is raised the server responds by returning an HTTP error code -*and* an error page. You can use the ``HTTPError`` instance as a response on the +*and* an error page. You can use the :exc:`HTTPError` instance as a response on the page returned. This means that as well as the code attribute, it also has read, geturl, and info, methods as returned by the ``urllib.response`` module:: @@ -327,7 +328,7 @@ geturl, and info, methods as returned by the ``urllib.response`` module:: Wrapping it Up -------------- -So if you want to be prepared for ``HTTPError`` *or* ``URLError`` there are two +So if you want to be prepared for :exc:`HTTPError` *or* :exc:`URLError` there are two basic approaches. I prefer the second approach. Number 1 @@ -354,7 +355,7 @@ Number 1 .. note:: The ``except HTTPError`` *must* come first, otherwise ``except URLError`` - will *also* catch an ``HTTPError``. + will *also* catch an :exc:`HTTPError`. Number 2 ~~~~~~~~ @@ -380,9 +381,9 @@ Number 2 info and geturl =============== -The response returned by urlopen (or the ``HTTPError`` instance) has two useful -methods ``info`` and ``geturl`` and is defined in the module -:mod:`urllib.response`. +The response returned by urlopen (or the :exc:`HTTPError` instance) has two +useful methods :meth:`info` and :meth:`geturl` and is defined in the module +:mod:`urllib.response`.. **geturl** - this returns the real URL of the page fetched. This is useful because ``urlopen`` (or the opener object used) may have followed a diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst index 9156bd2..cacb5ab 100644 --- a/Doc/library/ctypes.rst +++ b/Doc/library/ctypes.rst @@ -1390,7 +1390,7 @@ ctypes private copy to `value` and returns the former value. The *use_last_error* parameter, when set to True, enables the same mechanism for the Windows error code which is managed by the -GetLastError() and SetLastError() Windows api functions; +:func:`GetLastError` and :func:`SetLastError` Windows API functions; `ctypes.get_last_error()` and `ctypes.set_last_error(value)` are used to request and change the ctypes private copy of the windows error code. diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst index 7badbc3..d91c823 100644 --- a/Doc/library/multiprocessing.rst +++ b/Doc/library/multiprocessing.rst @@ -16,6 +16,13 @@ to this, the :mod:`multiprocessing` module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows. +.. warning:: + + Some of this package's functionality requires a functioning shared semaphore + implementation on the host operating system. Without one, the + :mod:`multiprocessing.synchronize` module will be disabled, and attempts to + import it will result in an :exc:`ImportError`. See + :issue:`3770` for additional information. The :class:`Process` class ~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Doc/library/optparse.rst b/Doc/library/optparse.rst index 4936e7d..3d8b43c 100644 --- a/Doc/library/optparse.rst +++ b/Doc/library/optparse.rst @@ -597,7 +597,7 @@ There are two broad classes of errors that :mod:`optparse` has to worry about: programmer errors and user errors. Programmer errors are usually erroneous calls to ``parser.add_option()``, e.g. invalid option strings, unknown option attributes, missing option attributes, etc. These are dealt with in the usual -way: raise an exception (either ``optparse.OptionError`` or ``TypeError``) and +way: raise an exception (either ``optparse.OptionError`` or :exc:`TypeError`) and let the program crash. Handling user errors is much more important, since they are guaranteed to happen @@ -794,10 +794,10 @@ And to define an option with only a long option string:: The keyword arguments define attributes of the new Option object. The most important option attribute is :attr:`action`, and it largely determines which other attributes are relevant or required. If you pass irrelevant option -attributes, or fail to pass required ones, :mod:`optparse` raises an OptionError -exception explaining your mistake. +attributes, or fail to pass required ones, :mod:`optparse` raises an +:exc:`OptionError` exception explaining your mistake. -An options's *action* determines what :mod:`optparse` does when it encounters +An option's *action* determines what :mod:`optparse` does when it encounters this option on the command-line. The standard option actions hard-coded into :mod:`optparse` are: @@ -1054,7 +1054,7 @@ Option attributes The following option attributes may be passed as keyword arguments to ``parser.add_option()``. If you pass an option attribute that is not relevant to a particular option, or fail to pass a required option attribute, -:mod:`optparse` raises OptionError. +:mod:`optparse` raises :exc:`OptionError`. * :attr:`action` (default: ``"store"``) @@ -1147,7 +1147,7 @@ error message. ``choice`` options are a subtype of ``string`` options. The ``choices`` option attribute (a sequence of strings) defines the set of allowed option arguments. ``optparse.check_choice()`` compares user-supplied option arguments against this -master list and raises OptionValueError if an invalid string is given. +master list and raises :exc:`OptionValueError` if an invalid string is given. .. _optparse-parsing-arguments: @@ -1220,10 +1220,10 @@ OptionParser provides several methods to help you out: (e.g., ``"-q"`` or ``"--verbose"``). ``remove_option(opt_str)`` - If the OptionParser has an option corresponding to ``opt_str``, that option is + If the :class:`OptionParser` has an option corresponding to ``opt_str``, that option is removed. If that option provided any other option strings, all of those option strings become invalid. If ``opt_str`` does not occur in any option belonging to - this OptionParser, raises ValueError. + this :class:`OptionParser`, raises :exc:`ValueError`. .. _optparse-conflicts-between-options: @@ -1254,13 +1254,13 @@ or with a separate call:: The available conflict handlers are: ``error`` (default) - assume option conflicts are a programming error and raise OptionConflictError + assume option conflicts are a programming error and raise :exc:`OptionConflictError` ``resolve`` resolve option conflicts intelligently (see below) -As an example, let's define an OptionParser that resolves conflicts +As an example, let's define an :class:`OptionParser` that resolves conflicts intelligently and add conflicting options to it:: parser = OptionParser(conflict_handler="resolve") @@ -1490,7 +1490,7 @@ where Raising errors in a callback ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The callback function should raise OptionValueError if there are any problems +The callback function should raise :exc:`OptionValueError` if there are any problems with the option or its argument(s). :mod:`optparse` catches this and terminates the program, printing the error message you supply to stderr. Your message should be clear, concise, accurate, and mention the option at fault. Otherwise, @@ -1691,9 +1691,9 @@ type-checking function will wind up in the OptionValues instance returned by :meth:`OptionParser.parse_args`, or be passed to a callback as the ``value`` parameter. -Your type-checking function should raise OptionValueError if it encounters any -problems. OptionValueError takes a single string argument, which is passed -as-is to OptionParser's :meth:`error` method, which in turn prepends the program +Your type-checking function should raise :exc:`OptionValueError` if it encounters any +problems. :exc:`OptionValueError` takes a single string argument, which is passed +as-is to :class:`OptionParser`'s :meth:`error` method, which in turn prepends the program name and the string ``"error:"`` and prints everything to stderr before terminating the process. diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst index 66e3c83..56edd1e 100644 --- a/Doc/library/subprocess.rst +++ b/Doc/library/subprocess.rst @@ -133,7 +133,7 @@ This module also defines four shortcut functions: .. function:: check_call(*popenargs, **kwargs) Run command with arguments. Wait for command to complete. If the exit code was - zero then return, otherwise raise :exc:`CalledProcessError.` The + zero then return, otherwise raise :exc:`CalledProcessError`. The :exc:`CalledProcessError` object will have the return code in the :attr:`returncode` attribute. diff --git a/Doc/tools/sphinxext/download.html b/Doc/tools/sphinxext/download.html index 01ce8a0..1f51399 100644 --- a/Doc/tools/sphinxext/download.html +++ b/Doc/tools/sphinxext/download.html @@ -3,14 +3,15 @@ {% set dlbase = 'http://docs.python.org/ftp/python/doc/' + release %} {% block body %} -<h1>Download Python {{ release }} Documentation - {%- if last_updated %} (last updated on {{ last_updated }}){% endif %}</h1> +<h1>Download Python {{ release }} Documentation</h1> {% if 'a' in release or 'b' in release or 'c' in release %} <p>We don't package the documentation for development releases for download. Downloads will be available for the final release.</p> {% else %} +{% if last_updated %}<p><b>Last updated on: {{ last_updated }}.</b></p>{% endif %} + <p>To download an archive containing all the documents for this version of Python in one of various formats, follow one of links in this table. The numbers in the table are the size of the download files in Kilobytes.</p> |