mirror of
https://github.com/python/cpython.git
synced 2025-08-03 08:34:29 +00:00
Merged revisions 59921-59932 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk ........ r59923 | raymond.hettinger | 2008-01-11 19:04:55 +0100 (Fri, 11 Jan 2008) | 1 line Speed-up and simplify code urlparse's result objects. ........ r59924 | andrew.kuchling | 2008-01-11 20:33:24 +0100 (Fri, 11 Jan 2008) | 1 line Bug #1790: update link; remove outdated paragraph ........ r59925 | thomas.heller | 2008-01-11 20:34:06 +0100 (Fri, 11 Jan 2008) | 5 lines Raise an error instead of crashing with a segfault when a NULL function pointer is called. Will backport to release25-maint. ........ r59927 | thomas.heller | 2008-01-11 21:29:19 +0100 (Fri, 11 Jan 2008) | 4 lines Fix a potential 'SystemError: NULL result without error'. NULL may be a valid return value from PyLong_AsVoidPtr. Will backport to release25-maint. ........ r59928 | raymond.hettinger | 2008-01-12 00:25:18 +0100 (Sat, 12 Jan 2008) | 1 line Update the opcode docs for STORE_MAP and BUILD_MAP ........ r59929 | mark.dickinson | 2008-01-12 02:56:00 +0100 (Sat, 12 Jan 2008) | 4 lines Issue 1780: Allow leading and trailing whitespace in Decimal constructor, when constructing from a string. Disallow trailing newlines in Context.create_decimal. ........ r59930 | georg.brandl | 2008-01-12 11:53:29 +0100 (Sat, 12 Jan 2008) | 3 lines Move OSError docs to exceptions doc, remove obsolete descriptions from os docs, rework posix docs. ........ r59931 | georg.brandl | 2008-01-12 14:47:57 +0100 (Sat, 12 Jan 2008) | 3 lines Patch #1700288: Method cache optimization, by Armin Rigo, ported to 2.6 by Kevin Jacobs. ........ r59932 | georg.brandl | 2008-01-12 17:11:09 +0100 (Sat, 12 Jan 2008) | 2 lines Fix editing glitch. ........
This commit is contained in:
parent
25bb783c03
commit
a62da1daaf
14 changed files with 317 additions and 141 deletions
|
@ -276,9 +276,10 @@ Decimal objects
|
|||
|
||||
Construct a new :class:`Decimal` object based from *value*.
|
||||
|
||||
*value* can be an integer, string, tuple, or another :class:`Decimal` object. If
|
||||
no *value* is given, returns ``Decimal("0")``. If *value* is a string, it
|
||||
should conform to the decimal numeric string syntax::
|
||||
*value* can be an integer, string, tuple, or another :class:`Decimal`
|
||||
object. If no *value* is given, returns ``Decimal("0")``. If *value* is a
|
||||
string, it should conform to the decimal numeric string syntax after leading
|
||||
and trailing whitespace characters are removed::
|
||||
|
||||
sign ::= '+' | '-'
|
||||
digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
|
||||
|
@ -308,6 +309,10 @@ Decimal objects
|
|||
|
||||
Once constructed, :class:`Decimal` objects are immutable.
|
||||
|
||||
.. versionchanged:: 2.6
|
||||
leading and trailing whitespace characters are permitted when
|
||||
creating a Decimal instance from a string.
|
||||
|
||||
Decimal floating point objects share many properties with the other built-in
|
||||
numeric types such as :class:`float` and :class:`int`. All of the usual math
|
||||
operations and special methods apply. Likewise, decimal objects can be copied,
|
||||
|
@ -925,6 +930,9 @@ method. For example, ``C.exp(x)`` is equivalent to
|
|||
>>> Decimal("3.4445") + Decimal(0) + Decimal("1.0023")
|
||||
Decimal("4.44")
|
||||
|
||||
This method implements the to-number operation of the IBM
|
||||
specification. If the argument is a string, no leading or trailing
|
||||
whitespace is permitted.
|
||||
|
||||
.. method:: Context.Etiny()
|
||||
|
||||
|
|
|
@ -506,10 +506,10 @@ the more significant byte last.
|
|||
Works as ``BUILD_TUPLE``, but creates a set.
|
||||
|
||||
|
||||
.. opcode:: BUILD_MAP (zero)
|
||||
.. opcode:: BUILD_MAP (count)
|
||||
|
||||
Pushes a new empty dictionary object onto the stack. The argument is ignored
|
||||
and set to zero by the compiler.
|
||||
Pushes a new dictionary object onto the stack. The dictionary is pre-sized
|
||||
to hold *count* entries.
|
||||
|
||||
|
||||
.. opcode:: LOAD_ATTR (namei)
|
||||
|
@ -589,6 +589,10 @@ the more significant byte last.
|
|||
Pushes a try block from a try-except clause onto the block stack. *delta* points
|
||||
to the finally block.
|
||||
|
||||
.. opcode:: STORE_MAP ()
|
||||
|
||||
Store a key and value pair in a dictionary. Pops the key and value while leaving
|
||||
the dictionary on the stack.
|
||||
|
||||
.. opcode:: LOAD_FAST (var_num)
|
||||
|
||||
|
|
|
@ -207,9 +207,19 @@ The following exceptions are the exceptions that are actually raised.
|
|||
|
||||
.. exception:: OSError
|
||||
|
||||
This class is derived from :exc:`EnvironmentError` and is used primarily as the
|
||||
:mod:`os` module's ``os.error`` exception. See :exc:`EnvironmentError` above for
|
||||
a description of the possible associated values.
|
||||
.. index:: module: errno
|
||||
|
||||
This exception is derived from :exc:`EnvironmentError`. It is raised when a
|
||||
function returns a system-related error (not for illegal argument types or
|
||||
other incidental errors). The :attr:`errno` attribute is a numeric error
|
||||
code from :cdata:`errno`, and the :attr:`strerror` attribute is the
|
||||
corresponding string, as would be printed by the C function :cfunc:`perror`.
|
||||
See the module :mod:`errno`, which contains names for the error codes defined
|
||||
by the underlying operating system.
|
||||
|
||||
For exceptions that involve a file system path (such as :func:`chdir` or
|
||||
:func:`unlink`), the exception instance will contain a third attribute,
|
||||
:attr:`filename`, which is the file name passed to the function.
|
||||
|
||||
|
||||
.. exception:: OverflowError
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
:mod:`os` --- Miscellaneous operating system interfaces
|
||||
=======================================================
|
||||
|
||||
|
@ -6,53 +5,32 @@
|
|||
:synopsis: Miscellaneous operating system interfaces.
|
||||
|
||||
|
||||
This module provides a more portable way of using operating system dependent
|
||||
functionality than importing an operating system dependent built-in module like
|
||||
:mod:`posix` or :mod:`nt`. If you just want to read or write a file see
|
||||
:func:`open`, if you want to manipulate paths, see the :mod:`os.path`
|
||||
module, and if you want to read all the lines in all the files on the
|
||||
command line see the :mod:`fileinput` module. For creating temporary
|
||||
files and directories see the :mod:`tempfile` module, and for high-level
|
||||
file and directory handling see the :mod:`shutil` module.
|
||||
This module provides a portable way of using operating system dependent
|
||||
functionality. If you just want to read or write a file see :func:`open`, if
|
||||
you want to manipulate paths, see the :mod:`os.path` module, and if you want to
|
||||
read all the lines in all the files on the command line see the :mod:`fileinput`
|
||||
module. For creating temporary files and directories see the :mod:`tempfile`
|
||||
module, and for high-level file and directory handling see the :mod:`shutil`
|
||||
module.
|
||||
|
||||
This module searches for an operating system dependent built-in module like
|
||||
:mod:`mac` or :mod:`posix` and exports the same functions and data as found
|
||||
there. The design of all built-in operating system dependent modules of Python
|
||||
is such that as long as the same functionality is available, it uses the same
|
||||
interface; for example, the function ``os.stat(path)`` returns stat information
|
||||
about *path* in the same format (which happens to have originated with the POSIX
|
||||
The design of all built-in operating system dependent modules of Python is such
|
||||
that as long as the same functionality is available, it uses the same interface;
|
||||
for example, the function ``os.stat(path)`` returns stat information about
|
||||
*path* in the same format (which happens to have originated with the POSIX
|
||||
interface).
|
||||
|
||||
Extensions peculiar to a particular operating system are also available through
|
||||
the :mod:`os` module, but using them is of course a threat to portability!
|
||||
|
||||
Note that after the first time :mod:`os` is imported, there is *no* performance
|
||||
penalty in using functions from :mod:`os` instead of directly from the operating
|
||||
system dependent built-in module, so there should be *no* reason not to use
|
||||
:mod:`os`!
|
||||
.. note::
|
||||
|
||||
The :mod:`os` module contains many functions and data values. The items below
|
||||
and in the following sub-sections are all available directly from the :mod:`os`
|
||||
module.
|
||||
All functions in this module raise :exc:`OSError` in the case of invalid or
|
||||
inaccessible file names and paths, or other arguments that have the correct
|
||||
type, but are not accepted by the operating system.
|
||||
|
||||
.. exception:: error
|
||||
|
||||
.. index:: module: errno
|
||||
|
||||
This exception is raised when a function returns a system-related error (not for
|
||||
illegal argument types or other incidental errors). This is also known as the
|
||||
built-in exception :exc:`OSError`. The accompanying value is a pair containing
|
||||
the numeric error code from :cdata:`errno` and the corresponding string, as
|
||||
would be printed by the C function :cfunc:`perror`. See the module
|
||||
:mod:`errno`, which contains names for the error codes defined by the underlying
|
||||
operating system.
|
||||
|
||||
When exceptions are classes, this exception carries two attributes,
|
||||
:attr:`errno` and :attr:`strerror`. The first holds the value of the C
|
||||
:cdata:`errno` variable, and the latter holds the corresponding error message
|
||||
from :cfunc:`strerror`. For exceptions that involve a file system path (such as
|
||||
:func:`chdir` or :func:`unlink`), the exception instance will contain a third
|
||||
attribute, :attr:`filename`, which is the file name passed to the function.
|
||||
An alias for the built-in :exc:`OSError` exception.
|
||||
|
||||
|
||||
.. data:: name
|
||||
|
@ -645,7 +623,6 @@ platforms. For descriptions of their availability and use, consult
|
|||
Files and Directories
|
||||
---------------------
|
||||
|
||||
|
||||
.. function:: access(path, mode)
|
||||
|
||||
Use the real uid/gid to test for access to *path*. Note that most operations
|
||||
|
@ -1760,8 +1737,8 @@ Miscellaneous System Information
|
|||
|
||||
.. function:: getloadavg()
|
||||
|
||||
Return the number of processes in the system run queue averaged over the last 1,
|
||||
5, and 15 minutes or raises :exc:`OSError` if the load average was
|
||||
Return the number of processes in the system run queue averaged over the last
|
||||
1, 5, and 15 minutes or raises :exc:`OSError` if the load average was
|
||||
unobtainable.
|
||||
|
||||
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
:mod:`posix` --- The most common POSIX system calls
|
||||
===================================================
|
||||
|
||||
|
@ -22,13 +21,8 @@ available through the :mod:`os` interface. Once :mod:`os` is imported, there is
|
|||
:mod:`os` provides some additional functionality, such as automatically calling
|
||||
:func:`putenv` when an entry in ``os.environ`` is changed.
|
||||
|
||||
The descriptions below are very terse; refer to the corresponding Unix manual
|
||||
(or POSIX documentation) entry for more information. Arguments called *path*
|
||||
refer to a pathname given as a string.
|
||||
|
||||
Errors are reported as exceptions; the usual exceptions are given for type
|
||||
errors, while errors reported by the system calls raise :exc:`error` (a synonym
|
||||
for the standard exception :exc:`OSError`), described below.
|
||||
errors, while errors reported by the system calls raise :exc:`OSError`.
|
||||
|
||||
|
||||
.. _posix-large-files:
|
||||
|
@ -42,9 +36,8 @@ Large File Support
|
|||
|
||||
.. sectionauthor:: Steve Clift <clift@mail.anacapa.net>
|
||||
|
||||
|
||||
Several operating systems (including AIX, HPUX, Irix and Solaris) provide
|
||||
support for files that are larger than 2 Gb from a C programming model where
|
||||
Several operating systems (including AIX, HP-UX, Irix and Solaris) provide
|
||||
support for files that are larger than 2 GB from a C programming model where
|
||||
:ctype:`int` and :ctype:`long` are 32-bit values. This is typically accomplished
|
||||
by defining the relevant size and offset types as 64-bit values. Such files are
|
||||
sometimes referred to as :dfn:`large files`.
|
||||
|
@ -67,16 +60,16 @@ On large-file-capable Linux systems, this might work::
|
|||
|
||||
.. _posix-contents:
|
||||
|
||||
Module Contents
|
||||
---------------
|
||||
|
||||
Module :mod:`posix` defines the following data item:
|
||||
Notable Module Contents
|
||||
-----------------------
|
||||
|
||||
In addition to many functions described in the :mod:`os` module documentation,
|
||||
:mod:`posix` defines the following data item:
|
||||
|
||||
.. data:: environ
|
||||
|
||||
A dictionary representing the string environment at the time the interpreter was
|
||||
started. For example, ``environ['HOME']`` is the pathname of your home
|
||||
A dictionary representing the string environment at the time the interpreter
|
||||
was started. For example, ``environ['HOME']`` is the pathname of your home
|
||||
directory, equivalent to ``getenv("HOME")`` in C.
|
||||
|
||||
Modifying this dictionary does not affect the string environment passed on by
|
||||
|
@ -90,7 +83,3 @@ Module :mod:`posix` defines the following data item:
|
|||
updates the environment on modification. Note also that updating ``os.environ``
|
||||
will render this dictionary obsolete. Use of the :mod:`os` module version of
|
||||
this is recommended over direct access to the :mod:`posix` module.
|
||||
|
||||
Additional contents of this module should only be accessed via the :mod:`os`
|
||||
module; refer to the documentation for that module for further information.
|
||||
|
||||
|
|
|
@ -110,12 +110,11 @@ between conformable Python objects and XML on the wire.
|
|||
.. seealso::
|
||||
|
||||
`XML-RPC HOWTO <http://www.tldp.org/HOWTO/XML-RPC-HOWTO/index.html>`_
|
||||
A good description of XML operation and client software in several languages.
|
||||
A good description of XML-RPC operation and client software in several languages.
|
||||
Contains pretty much everything an XML-RPC client developer needs to know.
|
||||
|
||||
`XML-RPC Hacks page <http://xmlrpc-c.sourceforge.net/hacks.php>`_
|
||||
Extensions for various open-source libraries to support introspection and
|
||||
multicall.
|
||||
`XML-RPC Introspection <http://xmlrpc-c.sourceforge.net/introspection.html>`_
|
||||
Describes the XML-RPC protocol extension for introspection.
|
||||
|
||||
|
||||
.. _serverproxy-objects:
|
||||
|
@ -167,11 +166,6 @@ grouped under the reserved :attr:`system` member:
|
|||
no such string is available, an empty string is returned. The documentation
|
||||
string may contain HTML markup.
|
||||
|
||||
Introspection methods are currently supported by servers written in PHP, C and
|
||||
Microsoft .NET. Partial introspection support is included in recent updates to
|
||||
UserLand Frontier. Introspection support for Perl, Python and Java is available
|
||||
at the `XML-RPC Hacks <http://xmlrpc-c.sourceforge.net/hacks.php>`_ page.
|
||||
|
||||
|
||||
.. _boolean-objects:
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue