.. 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)
.. 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.
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.
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
}
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::
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
.. note::
The ``except HTTPError`` *must* come first, otherwise ``except URLError``
- will *also* catch an ``HTTPError``.
+ will *also* catch an :exc:`HTTPError`.
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
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.
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
~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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:
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"``)
``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:
(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:
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")
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,
: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.
.. 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.
{% 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>
from multiprocessing.util import Finalize, register_after_fork, debug
from multiprocessing.forking import assert_spawning, Popen
+# Try to import the mp.synchronize module cleanly, if it fails
+# raise ImportError for platforms lacking a working sem_open implementation.
+# See issue 3770
+try:
+ from _multiprocessing import SemLock
+except (ImportError):
+ raise ImportError("This platform lacks a functioning sem_open" +
+ " implementation, therefore, the required" +
+ " synchronization primitives needed will not" +
+ " function, see issue 3770.")
+
#
# Constants
#
test_tcl
test_timeout
test_urllibnet
+ test_multiprocessing
""",
'aix5':
"""
test_ossaudiodev
test_pep277
test_tcl
+ test_multiprocessing
""",
'netbsd3':
"""
test_ossaudiodev
test_pep277
test_tcl
+ test_multiprocessing
""",
}
_expectations['freebsd5'] = _expectations['freebsd4']
import random
import logging
+
+# Work around broken sem_open implementations
+try:
+ import multiprocessing.synchronize
+except ImportError as e:
+ from test.test_support import TestSkipped
+ raise TestSkipped(e)
+
import multiprocessing.dummy
import multiprocessing.connection
import multiprocessing.managers
build process will automatically select the latest version.
You must install the NASM assembler from
- http://www.kernel.org/pub/software/devel/nasm/binaries/win32/
+ http://nasm.sf.net
for x86 builds. Put nasmw.exe anywhere in your PATH.
You can also install ActivePerl from
)
libraries = []
+ elif platform.startswith('openbsd'):
+ macros = dict( # OpenBSD
+ HAVE_SEM_OPEN=0, # Not implemented
+ HAVE_SEM_TIMEDWAIT=0,
+ HAVE_FD_TRANSFER=1,
+ )
+ libraries = []
+
else: # Linux and other unices
macros = dict(
HAVE_SEM_OPEN=1,
projects / python / commitdiff