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.) ........
This commit is contained in:
Benjamin Peterson
parent
7d8d9a588c
commit
e5384b0886
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -21,6 +21,17 @@ from multiprocessing.process import current_process
|
|||
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
|
||||
#
|
||||
|
|
|
|||
|
|
@ -1075,6 +1075,7 @@ _expectations = {
|
|||
test_tcl
|
||||
test_timeout
|
||||
test_urllibnet
|
||||
test_multiprocessing
|
||||
""",
|
||||
'aix5':
|
||||
"""
|
||||
|
|
@ -1102,6 +1103,7 @@ _expectations = {
|
|||
test_ossaudiodev
|
||||
test_pep277
|
||||
test_tcl
|
||||
test_multiprocessing
|
||||
""",
|
||||
'netbsd3':
|
||||
"""
|
||||
|
|
@ -1115,6 +1117,7 @@ _expectations = {
|
|||
test_ossaudiodev
|
||||
test_pep277
|
||||
test_tcl
|
||||
test_multiprocessing
|
||||
""",
|
||||
}
|
||||
_expectations['freebsd5'] = _expectations['freebsd4']
|
||||
|
|
|
|||
|
|
@ -18,6 +18,14 @@ import socket
|
|||
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
|
||||
|
|
|
|||
|
|
@ -153,7 +153,7 @@ _ssl
|
|||
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
|
||||
|
|
|
|||
8
setup.py
8
setup.py
|
|
@ -1019,6 +1019,14 @@ class PyBuildExt(build_ext):
|
|||
)
|
||||
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,
|
||||
|
|
|
|||
Loading…
Reference in New Issue