mirror of
https://github.com/python/cpython.git
synced 2024-11-23 18:04:37 +08:00
Docs: remove redundant "adverb-adjective" hyphens from compound modifiers (GH-94551)
Discussion: https://discuss.python.org/t/slight-grammar-fix-throughout-adverbs-dont-need-hyphen/17021
This commit is contained in:
parent
2b8ed4d3d4
commit
3440d197a5
@ -14,7 +14,7 @@ Allocating Objects on the Heap
|
||||
|
||||
.. c:function:: PyObject* PyObject_Init(PyObject *op, PyTypeObject *type)
|
||||
|
||||
Initialize a newly-allocated object *op* with its type and initial
|
||||
Initialize a newly allocated object *op* with its type and initial
|
||||
reference. Returns the initialized object. If *type* indicates that the
|
||||
object participates in the cyclic garbage detector, it is added to the
|
||||
detector's set of observed objects. Other fields of the object are not
|
||||
|
@ -779,7 +779,7 @@ A full list of the various types of debugging builds is in the file
|
||||
:file:`Misc/SpecialBuilds.txt` in the Python source distribution. Builds are
|
||||
available that support tracing of reference counts, debugging the memory
|
||||
allocator, or low-level profiling of the main interpreter loop. Only the most
|
||||
frequently-used builds will be described in the remainder of this section.
|
||||
frequently used builds will be described in the remainder of this section.
|
||||
|
||||
Compiling the interpreter with the :c:macro:`Py_DEBUG` macro defined produces
|
||||
what is generally meant by :ref:`a debug build of Python <debug-build>`.
|
||||
|
@ -75,7 +75,7 @@ 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
|
||||
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
|
||||
|
@ -529,7 +529,7 @@ type objects) *must* have the :attr:`ob_size` field.
|
||||
``PyObject_HEAD_INIT`` macro. For :ref:`statically allocated objects
|
||||
<static-types>`, these fields always remain ``NULL``. For :ref:`dynamically
|
||||
allocated objects <heap-types>`, these two fields are used to link the
|
||||
object into a doubly-linked list of *all* live objects on the heap.
|
||||
object into a doubly linked list of *all* live objects on the heap.
|
||||
|
||||
This could be used for various debugging purposes; currently the only uses
|
||||
are the :func:`sys.getobjects` function and to print the objects that are
|
||||
|
@ -35,7 +35,7 @@ as much as it can.
|
||||
callable object that receives notification when *ob* is garbage collected; it
|
||||
should accept a single parameter, which will be the weak reference object
|
||||
itself. *callback* may also be ``None`` or ``NULL``. If *ob* is not a
|
||||
weakly-referencable object, or if *callback* is not callable, ``None``, or
|
||||
weakly referencable object, or if *callback* is not callable, ``None``, or
|
||||
``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ as much as it can.
|
||||
be a callable object that receives notification when *ob* is garbage
|
||||
collected; it should accept a single parameter, which will be the weak
|
||||
reference object itself. *callback* may also be ``None`` or ``NULL``. If *ob*
|
||||
is not a weakly-referencable object, or if *callback* is not callable,
|
||||
is not a weakly referencable object, or if *callback* is not callable,
|
||||
``None``, or ``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
|
||||
|
||||
|
||||
|
@ -1198,7 +1198,7 @@ other utility module.
|
||||
it contains certain values: see :func:`check_environ`. Raise :exc:`ValueError`
|
||||
for any variables not found in either *local_vars* or ``os.environ``.
|
||||
|
||||
Note that this is not a fully-fledged string interpolation function. A valid
|
||||
Note that this is not a full-fledged string interpolation function. A valid
|
||||
``$variable`` can consist only of upper and lower case letters, numbers and an
|
||||
underscore. No { } or ( ) style quoting is available.
|
||||
|
||||
|
@ -17,7 +17,7 @@ The initialization function has the signature:
|
||||
|
||||
.. c:function:: PyObject* PyInit_modulename(void)
|
||||
|
||||
It returns either a fully-initialized module, or a :c:type:`PyModuleDef`
|
||||
It returns either a fully initialized module, or a :c:type:`PyModuleDef`
|
||||
instance. See :ref:`initializing-modules` for details.
|
||||
|
||||
.. highlight:: python
|
||||
|
@ -175,7 +175,7 @@ example::
|
||||
}
|
||||
|
||||
If no :c:member:`~PyTypeObject.tp_repr` handler is specified, the interpreter will supply a
|
||||
representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely-identifying
|
||||
representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely identifying
|
||||
value for the object.
|
||||
|
||||
The :c:member:`~PyTypeObject.tp_str` handler is to :func:`str` what the :c:member:`~PyTypeObject.tp_repr` handler
|
||||
@ -589,7 +589,7 @@ with the required field::
|
||||
PyObject *weakreflist; /* List of weak references */
|
||||
} TrivialObject;
|
||||
|
||||
And the corresponding member in the statically-declared type object::
|
||||
And the corresponding member in the statically declared type object::
|
||||
|
||||
static PyTypeObject TrivialType = {
|
||||
PyVarObject_HEAD_INIT(NULL, 0)
|
||||
|
@ -313,7 +313,7 @@ you're too lazy to define a function.
|
||||
|
||||
Functions are already first class objects in Python, and can be declared in a
|
||||
local scope. Therefore the only advantage of using a lambda instead of a
|
||||
locally-defined function is that you don't need to invent a name for the
|
||||
locally defined function is that you don't need to invent a name for the
|
||||
function -- but that's just a local variable to which the function object (which
|
||||
is exactly the same type of object that a lambda expression yields) is assigned!
|
||||
|
||||
|
@ -294,7 +294,7 @@ It's good practice if you import modules in the following order:
|
||||
1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
|
||||
2. third-party library modules (anything installed in Python's site-packages
|
||||
directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
|
||||
3. locally-developed modules
|
||||
3. locally developed modules
|
||||
|
||||
It is sometimes necessary to move imports to a function or class to avoid
|
||||
problems with circular imports. Gordon McMillan says:
|
||||
@ -771,7 +771,7 @@ What does the slash(/) in the parameter list of a function mean?
|
||||
|
||||
A slash in the argument list of a function denotes that the parameters prior to
|
||||
it are positional-only. Positional-only parameters are the ones without an
|
||||
externally-usable name. Upon calling a function that accepts positional-only
|
||||
externally usable name. Upon calling a function that accepts positional-only
|
||||
parameters, arguments are mapped to parameters based solely on their position.
|
||||
For example, :func:`divmod` is a function that accepts positional-only
|
||||
parameters. Its documentation looks like this::
|
||||
|
@ -532,7 +532,7 @@ Glossary
|
||||
machines.
|
||||
|
||||
However, some extension modules, either standard or third-party,
|
||||
are designed so as to release the GIL when doing computationally-intensive
|
||||
are designed so as to release the GIL when doing computationally intensive
|
||||
tasks such as compression or hashing. Also, the GIL is always released
|
||||
when doing I/O.
|
||||
|
||||
|
@ -541,7 +541,7 @@ Let's dive in!
|
||||
|
||||
16. Compile, then run the relevant portions of the regression-test suite.
|
||||
This change should not introduce any new compile-time warnings or errors,
|
||||
and there should be no externally-visible change to Python's behavior.
|
||||
and there should be no externally visible change to Python's behavior.
|
||||
|
||||
Well, except for one difference: ``inspect.signature()`` run on your function
|
||||
should now provide a valid signature!
|
||||
@ -1117,7 +1117,7 @@ Here's the syntax for cloning a function::
|
||||
``module.class`` in the sample just to illustrate that you must
|
||||
use the full path to *both* functions.)
|
||||
|
||||
Sorry, there's no syntax for partially-cloning a function, or cloning a function
|
||||
Sorry, there's no syntax for partially cloning a function, or cloning a function
|
||||
then modifying it. Cloning is an all-or nothing proposition.
|
||||
|
||||
Also, the function you are cloning from must have been previously defined
|
||||
@ -1315,7 +1315,7 @@ to specify in your subclass. Here's the current list:
|
||||
there is no default, but not specifying a default may
|
||||
result in an "uninitialized variable" warning. This can
|
||||
easily happen when using option groups—although
|
||||
properly-written code will never actually use this value,
|
||||
properly written code will never actually use this value,
|
||||
the variable does get passed in to the impl, and the
|
||||
C compiler will complain about the "use" of the
|
||||
uninitialized value. This value should always be a
|
||||
|
@ -741,7 +741,7 @@ further because you risk skipping a discarded element.
|
||||
The itertools module
|
||||
====================
|
||||
|
||||
The :mod:`itertools` module contains a number of commonly-used iterators as well
|
||||
The :mod:`itertools` module contains a number of commonly used iterators as well
|
||||
as functions for combining several iterators. This section will introduce the
|
||||
module's contents by showing small examples.
|
||||
|
||||
|
@ -123,7 +123,7 @@ Sufficiently modern readelf can print the metadata::
|
||||
Arguments: 8@%rbp 8@%r12 -4@%eax
|
||||
|
||||
The above metadata contains information for SystemTap describing how it
|
||||
can patch strategically-placed machine code instructions to enable the
|
||||
can patch strategically placed machine code instructions to enable the
|
||||
tracing hooks used by a SystemTap script.
|
||||
|
||||
|
||||
@ -410,7 +410,7 @@ needing to directly name the static markers:
|
||||
|
||||
|
||||
The following script uses the tapset above to provide a top-like view of all
|
||||
running CPython code, showing the top 20 most frequently-entered bytecode
|
||||
running CPython code, showing the top 20 most frequently entered bytecode
|
||||
frames, each second, across the whole system:
|
||||
|
||||
.. code-block:: none
|
||||
|
@ -127,7 +127,7 @@ Logging to a file
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
A very common situation is that of recording logging events in a file, so let's
|
||||
look at that next. Be sure to try the following in a newly-started Python
|
||||
look at that next. Be sure to try the following in a newly started Python
|
||||
interpreter, and don't just continue from the session described above::
|
||||
|
||||
import logging
|
||||
|
@ -949,7 +949,7 @@ Additionally, you can retrieve named groups as a dictionary with
|
||||
>>> m.groupdict()
|
||||
{'first': 'Jane', 'last': 'Doe'}
|
||||
|
||||
Named groups are handy because they let you use easily-remembered names, instead
|
||||
Named groups are handy because they let you use easily remembered names, instead
|
||||
of having to remember numbers. Here's an example RE from the :mod:`imaplib`
|
||||
module::
|
||||
|
||||
|
@ -420,7 +420,7 @@ Openers and Handlers
|
||||
====================
|
||||
|
||||
When you fetch a URL you use an opener (an instance of the perhaps
|
||||
confusingly-named :class:`urllib.request.OpenerDirector`). Normally we have been using
|
||||
confusingly named :class:`urllib.request.OpenerDirector`). Normally we have been using
|
||||
the default opener - via ``urlopen`` - but you can create custom
|
||||
openers. Openers use handlers. All the "heavy lifting" is done by the
|
||||
handlers. Each handler knows how to open URLs for a particular URL scheme (http,
|
||||
|
@ -65,7 +65,7 @@ If you download a module source distribution, you can tell pretty quickly if it
|
||||
was packaged and distributed in the standard way, i.e. using the Distutils.
|
||||
First, the distribution's name and version number will be featured prominently
|
||||
in the name of the downloaded archive, e.g. :file:`foo-1.0.tar.gz` or
|
||||
:file:`widget-0.9.7.zip`. Next, the archive will unpack into a similarly-named
|
||||
:file:`widget-0.9.7.zip`. Next, the archive will unpack into a similarly named
|
||||
directory: :file:`foo-1.0` or :file:`widget-0.9.7`. Additionally, the
|
||||
distribution will contain a setup script :file:`setup.py`, and a file named
|
||||
:file:`README.txt` or possibly just :file:`README`, which should explain that
|
||||
|
@ -125,7 +125,7 @@ connection requests.
|
||||
.. method:: async_chat.push_with_producer(producer)
|
||||
|
||||
Takes a producer object and adds it to the producer queue associated with
|
||||
the channel. When all currently-pushed producers have been exhausted the
|
||||
the channel. When all currently pushed producers have been exhausted the
|
||||
channel will consume this producer's data by calling its :meth:`more`
|
||||
method and send the data to the remote endpoint.
|
||||
|
||||
|
@ -8,7 +8,7 @@ The modules described in this chapter allow writing interfaces similar to
|
||||
Python's interactive interpreter. If you want a Python interpreter that
|
||||
supports some special feature in addition to the Python language, you should
|
||||
look at the :mod:`code` module. (The :mod:`codeop` module is lower-level, used
|
||||
to support compiling a possibly-incomplete chunk of Python code.)
|
||||
to support compiling a possibly incomplete chunk of Python code.)
|
||||
|
||||
The full list of modules described in this chapter is:
|
||||
|
||||
|
@ -30,7 +30,7 @@
|
||||
|
||||
--------------
|
||||
|
||||
The :mod:`decimal` module provides support for fast correctly-rounded
|
||||
The :mod:`decimal` module provides support for fast correctly rounded
|
||||
decimal floating point arithmetic. It offers several advantages over the
|
||||
:class:`float` datatype:
|
||||
|
||||
@ -1371,16 +1371,16 @@ In addition to the three supplied contexts, new contexts can be created with the
|
||||
With two arguments, compute ``x**y``. If ``x`` is negative then ``y``
|
||||
must be integral. The result will be inexact unless ``y`` is integral and
|
||||
the result is finite and can be expressed exactly in 'precision' digits.
|
||||
The rounding mode of the context is used. Results are always correctly-rounded
|
||||
The rounding mode of the context is used. Results are always correctly rounded
|
||||
in the Python version.
|
||||
|
||||
``Decimal(0) ** Decimal(0)`` results in ``InvalidOperation``, and if ``InvalidOperation``
|
||||
is not trapped, then results in ``Decimal('NaN')``.
|
||||
|
||||
.. versionchanged:: 3.3
|
||||
The C module computes :meth:`power` in terms of the correctly-rounded
|
||||
The C module computes :meth:`power` in terms of the correctly rounded
|
||||
:meth:`exp` and :meth:`ln` functions. The result is well-defined but
|
||||
only "almost always correctly-rounded".
|
||||
only "almost always correctly rounded".
|
||||
|
||||
With three arguments, compute ``(x**y) % modulo``. For the three argument
|
||||
form, the following restrictions on the arguments hold:
|
||||
@ -2151,7 +2151,7 @@ Q. Is the CPython implementation fast for large numbers?
|
||||
A. Yes. In the CPython and PyPy3 implementations, the C/CFFI versions of
|
||||
the decimal module integrate the high speed `libmpdec
|
||||
<https://www.bytereef.org/mpdecimal/doc/libmpdec/index.html>`_ library for
|
||||
arbitrary precision correctly-rounded decimal floating point arithmetic [#]_.
|
||||
arbitrary precision correctly rounded decimal floating point arithmetic [#]_.
|
||||
``libmpdec`` uses `Karatsuba multiplication
|
||||
<https://en.wikipedia.org/wiki/Karatsuba_algorithm>`_
|
||||
for medium-sized numbers and the `Number Theoretic Transform
|
||||
|
@ -565,12 +565,12 @@ doctest decides whether actual output matches an example's expected output:
|
||||
|
||||
When specified, doctests expecting exceptions pass so long as an exception
|
||||
of the expected type is raised, even if the details
|
||||
(message and fully-qualified exception name) don't match.
|
||||
(message and fully qualified exception name) don't match.
|
||||
|
||||
For example, an example expecting ``ValueError: 42`` will pass if the actual
|
||||
exception raised is ``ValueError: 3*14``, but will fail if, say, a
|
||||
:exc:`TypeError` is raised instead.
|
||||
It will also ignore any fully-qualified name included before the
|
||||
It will also ignore any fully qualified name included before the
|
||||
exception class, which can vary between implementations and versions
|
||||
of Python and the code/libraries in use.
|
||||
Hence, all three of these variations will work with the flag specified:
|
||||
|
@ -42,7 +42,7 @@ For example, ``'[?]'`` matches the character ``'?'``.
|
||||
.. function:: glob(pathname, *, root_dir=None, dir_fd=None, recursive=False, \
|
||||
include_hidden=False)
|
||||
|
||||
Return a possibly-empty list of path names that match *pathname*, which must be
|
||||
Return a possibly empty list of path names that match *pathname*, which must be
|
||||
a string containing a path specification. *pathname* can be either absolute
|
||||
(like :file:`/usr/src/Python-1.5/Makefile`) or relative (like
|
||||
:file:`../../Tools/\*/\*.gif`), and can contain shell-style wildcards. Broken
|
||||
|
@ -69,7 +69,7 @@ An HMAC object has the following methods:
|
||||
|
||||
.. warning::
|
||||
|
||||
When comparing the output of :meth:`digest` to an externally-supplied
|
||||
When comparing the output of :meth:`digest` to an externally supplied
|
||||
digest during a verification routine, it is recommended to use the
|
||||
:func:`compare_digest` function instead of the ``==`` operator
|
||||
to reduce the vulnerability to timing attacks.
|
||||
@ -83,7 +83,7 @@ An HMAC object has the following methods:
|
||||
|
||||
.. warning::
|
||||
|
||||
When comparing the output of :meth:`hexdigest` to an externally-supplied
|
||||
When comparing the output of :meth:`hexdigest` to an externally supplied
|
||||
digest during a verification routine, it is recommended to use the
|
||||
:func:`compare_digest` function instead of the ``==`` operator
|
||||
to reduce the vulnerability to timing attacks.
|
||||
|
@ -450,7 +450,7 @@ ABC hierarchy::
|
||||
reloaded):
|
||||
|
||||
- :attr:`__name__`
|
||||
The module's fully-qualified name.
|
||||
The module's fully qualified name.
|
||||
It is ``'__main__'`` for an executed module.
|
||||
|
||||
- :attr:`__file__`
|
||||
@ -471,7 +471,7 @@ ABC hierarchy::
|
||||
as an indicator that the module is a package.
|
||||
|
||||
- :attr:`__package__`
|
||||
The fully-qualified name of the package the module is in (or the
|
||||
The fully qualified name of the package the module is in (or the
|
||||
empty string for a top-level module).
|
||||
If the module is a package then this is the same as :attr:`__name__`.
|
||||
|
||||
@ -899,7 +899,7 @@ find and load modules.
|
||||
|
||||
(:attr:`__name__`)
|
||||
|
||||
The module's fully-qualified name.
|
||||
The module's fully qualified name.
|
||||
The :term:`finder` should always set this attribute to a non-empty string.
|
||||
|
||||
.. attribute:: loader
|
||||
@ -948,7 +948,7 @@ find and load modules.
|
||||
|
||||
(:attr:`__package__`)
|
||||
|
||||
(Read-only) The fully-qualified name of the package the module is in (or the
|
||||
(Read-only) The fully qualified name of the package the module is in (or the
|
||||
empty string for a top-level module).
|
||||
If the module is a package then this is the same as :attr:`name`.
|
||||
|
||||
|
@ -187,7 +187,7 @@ attributes:
|
||||
| | co_name | name with which this code |
|
||||
| | | object was defined |
|
||||
+-----------+-------------------+---------------------------+
|
||||
| | co_qualname | fully-qualified name with |
|
||||
| | co_qualname | fully qualified name with |
|
||||
| | | which this code object |
|
||||
| | | was defined |
|
||||
+-----------+-------------------+---------------------------+
|
||||
@ -1130,7 +1130,7 @@ Classes and functions
|
||||
doesn't have its own annotations dict, returns an empty dict.
|
||||
* All accesses to object members and dict values are done
|
||||
using ``getattr()`` and ``dict.get()`` for safety.
|
||||
* Always, always, always returns a freshly-created dict.
|
||||
* Always, always, always returns a freshly created dict.
|
||||
|
||||
``eval_str`` controls whether or not values of type ``str`` are replaced
|
||||
with the result of calling :func:`eval()` on those values:
|
||||
|
@ -1510,7 +1510,7 @@ The following exception classes are defined in the :mod:`mailbox` module:
|
||||
|
||||
Raised when some mailbox-related condition beyond the control of the program
|
||||
causes it to be unable to proceed, such as when failing to acquire a lock that
|
||||
another program already holds a lock, or when a uniquely-generated file name
|
||||
another program already holds a lock, or when a uniquely generated file name
|
||||
already exists.
|
||||
|
||||
|
||||
|
@ -529,7 +529,7 @@ help message:
|
||||
line-wrapping---\ :mod:`optparse` takes care of wrapping lines and making
|
||||
the help output look good.
|
||||
|
||||
* options that take a value indicate this fact in their automatically-generated
|
||||
* options that take a value indicate this fact in their automatically generated
|
||||
help message, e.g. for the "mode" option::
|
||||
|
||||
-m MODE, --mode=MODE
|
||||
@ -539,7 +539,7 @@ help message:
|
||||
:mod:`optparse` converts the destination variable name to uppercase and uses
|
||||
that for the meta-variable. Sometimes, that's not what you want---for
|
||||
example, the ``--filename`` option explicitly sets ``metavar="FILE"``,
|
||||
resulting in this automatically-generated option description::
|
||||
resulting in this automatically generated option description::
|
||||
|
||||
-f FILE, --filename=FILE
|
||||
|
||||
@ -1449,7 +1449,7 @@ intelligently and add conflicting options to it::
|
||||
parser.add_option("-n", "--dry-run", ..., help="do no harm")
|
||||
parser.add_option("-n", "--noisy", ..., help="be noisy")
|
||||
|
||||
At this point, :mod:`optparse` detects that a previously-added option is already
|
||||
At this point, :mod:`optparse` detects that a previously added option is already
|
||||
using the ``-n`` option string. Since ``conflict_handler`` is ``"resolve"``,
|
||||
it resolves the situation by removing ``-n`` from the earlier option's list of
|
||||
option strings. Now ``--dry-run`` is the only way for the user to activate
|
||||
@ -1460,7 +1460,7 @@ that option. If the user asks for help, the help message will reflect that::
|
||||
...
|
||||
-n, --noisy be noisy
|
||||
|
||||
It's possible to whittle away the option strings for a previously-added option
|
||||
It's possible to whittle away the option strings for a previously added option
|
||||
until there are none left, and the user has no way of invoking that option from
|
||||
the command-line. In that case, :mod:`optparse` removes that option completely,
|
||||
so it doesn't show up in help text or anywhere else. Carrying on with our
|
||||
|
@ -2121,7 +2121,7 @@ features:
|
||||
|
||||
The *mode* parameter is passed to :func:`mkdir` for creating the leaf
|
||||
directory; see :ref:`the mkdir() description <mkdir_modebits>` for how it
|
||||
is interpreted. To set the file permission bits of any newly-created parent
|
||||
is interpreted. To set the file permission bits of any newly created parent
|
||||
directories you can set the umask before invoking :func:`makedirs`. The
|
||||
file permission bits of existing parent directories are not changed.
|
||||
|
||||
@ -2152,7 +2152,7 @@ features:
|
||||
|
||||
.. versionchanged:: 3.7
|
||||
The *mode* argument no longer affects the file permission bits of
|
||||
newly-created intermediate-level directories.
|
||||
newly created intermediate-level directories.
|
||||
|
||||
|
||||
.. function:: mkfifo(path, mode=0o666, *, dir_fd=None)
|
||||
|
@ -44,7 +44,7 @@ randomness that your operating system provides.
|
||||
|
||||
.. function:: choice(sequence)
|
||||
|
||||
Return a randomly-chosen element from a non-empty sequence.
|
||||
Return a randomly chosen element from a non-empty sequence.
|
||||
|
||||
.. function:: randbelow(n)
|
||||
|
||||
@ -155,7 +155,7 @@ Generate an eight-character alphanumeric password:
|
||||
Applications should not
|
||||
`store passwords in a recoverable format <http://cwe.mitre.org/data/definitions/257.html>`_,
|
||||
whether plain text or encrypted. They should be salted and hashed
|
||||
using a cryptographically-strong one-way (irreversible) hash function.
|
||||
using a cryptographically strong one-way (irreversible) hash function.
|
||||
|
||||
|
||||
Generate a ten-character alphanumeric password with at least one
|
||||
|
@ -252,7 +252,7 @@ object.
|
||||
|
||||
.. method:: devpoll.poll([timeout])
|
||||
|
||||
Polls the set of registered file descriptors, and returns a possibly-empty list
|
||||
Polls the set of registered file descriptors, and returns a possibly empty list
|
||||
containing ``(fd, event)`` 2-tuples for the descriptors that have events or
|
||||
errors to report. *fd* is the file descriptor, and *event* is a bitmask with
|
||||
bits set for the reported events for that descriptor --- :const:`POLLIN` for
|
||||
@ -440,7 +440,7 @@ linearly scanned again. :c:func:`select` is O(highest file descriptor), while
|
||||
|
||||
.. method:: poll.poll([timeout])
|
||||
|
||||
Polls the set of registered file descriptors, and returns a possibly-empty list
|
||||
Polls the set of registered file descriptors, and returns a possibly empty list
|
||||
containing ``(fd, event)`` 2-tuples for the descriptors that have events or
|
||||
errors to report. *fd* is the file descriptor, and *event* is a bitmask with
|
||||
bits set for the reported events for that descriptor --- :const:`POLLIN` for
|
||||
|
@ -194,7 +194,7 @@ Directory and files operations
|
||||
|
||||
When *follow_symlinks* is false, and *src* is a symbolic
|
||||
link, :func:`copy2` attempts to copy all metadata from the
|
||||
*src* symbolic link to the newly-created *dst* symbolic link.
|
||||
*src* symbolic link to the newly created *dst* symbolic link.
|
||||
However, this functionality is not available on all platforms.
|
||||
On platforms where some or all of this functionality is
|
||||
unavailable, :func:`copy2` will preserve all the metadata
|
||||
|
@ -228,7 +228,7 @@ SMTPChannel Objects
|
||||
|
||||
.. attribute:: fqdn
|
||||
|
||||
Holds the fully-qualified domain name of the server as returned by
|
||||
Holds the fully qualified domain name of the server as returned by
|
||||
:func:`socket.getfqdn`.
|
||||
|
||||
.. attribute:: peer
|
||||
|
@ -125,7 +125,7 @@ created. Socket addresses are represented as follows:
|
||||
|
||||
- A string or a tuple ``(id, unit)`` is used for the :const:`SYSPROTO_CONTROL`
|
||||
protocol of the :const:`PF_SYSTEM` family. The string is the name of a
|
||||
kernel control using a dynamically-assigned ID. The tuple can be used if ID
|
||||
kernel control using a dynamically assigned ID. The tuple can be used if ID
|
||||
and unit number of the kernel control are known or if a registered ID is
|
||||
used.
|
||||
|
||||
@ -956,7 +956,7 @@ The :mod:`socket` module also offers various network-related services:
|
||||
.. function:: getnameinfo(sockaddr, flags)
|
||||
|
||||
Translate a socket address *sockaddr* into a 2-tuple ``(host, port)``. Depending
|
||||
on the settings of *flags*, the result can contain a fully-qualified domain name
|
||||
on the settings of *flags*, the result can contain a fully qualified domain name
|
||||
or numeric address representation in *host*. Similarly, *port* can contain a
|
||||
string port name or a numeric port number.
|
||||
|
||||
|
@ -683,7 +683,7 @@ Connection Objects
|
||||
|
||||
If returning a tuple doesn't suffice and you want name-based access to
|
||||
columns, you should consider setting :attr:`row_factory` to the
|
||||
highly-optimized :class:`sqlite3.Row` type. :class:`Row` provides both
|
||||
highly optimized :class:`sqlite3.Row` type. :class:`Row` provides both
|
||||
index-based and case-insensitive name-based access to columns with almost no
|
||||
memory overhead. It will probably be better than your own custom
|
||||
dictionary-based approach or even a db_row based solution.
|
||||
|
@ -82,7 +82,7 @@ The module defines the following exception and functions:
|
||||
|
||||
Iteratively unpack from the buffer *buffer* according to the format
|
||||
string *format*. This function returns an iterator which will read
|
||||
equally-sized chunks from the buffer until all its contents have been
|
||||
equally sized chunks from the buffer until all its contents have been
|
||||
consumed. The buffer's size in bytes must be a multiple of the size
|
||||
required by the format, as reflected by :func:`calcsize`.
|
||||
|
||||
|
@ -359,7 +359,7 @@ functions.
|
||||
|
||||
.. warning::
|
||||
|
||||
For maximum reliability, use a fully-qualified path for the executable.
|
||||
For maximum reliability, use a fully qualified path for the executable.
|
||||
To search for an unqualified name on :envvar:`PATH`, use
|
||||
:meth:`shutil.which`. On all platforms, passing :data:`sys.executable`
|
||||
is the recommended way to launch the current Python interpreter again,
|
||||
@ -1553,7 +1553,7 @@ On Linux, :mod:`subprocess` defaults to using the ``vfork()`` system call
|
||||
internally when it is safe to do so rather than ``fork()``. This greatly
|
||||
improves performance.
|
||||
|
||||
If you ever encounter a presumed highly-unusual situation where you need to
|
||||
If you ever encounter a presumed highly unusual situation where you need to
|
||||
prevent ``vfork()`` from being used by Python, you can set the
|
||||
:attr:`subprocess._USE_VFORK` attribute to a false value.
|
||||
|
||||
|
@ -839,7 +839,7 @@ There are three tar formats that can be created with the :mod:`tarfile` module:
|
||||
files and stores pathnames in a portable way. Modern tar implementations,
|
||||
including GNU tar, bsdtar/libarchive and star, fully support extended *pax*
|
||||
features; some old or unmaintained libraries may not, but should treat
|
||||
*pax* archives as if they were in the universally-supported *ustar* format.
|
||||
*pax* archives as if they were in the universally supported *ustar* format.
|
||||
It is the current default format for new archives.
|
||||
|
||||
It extends the existing *ustar* format with extra headers for information
|
||||
|
@ -286,7 +286,7 @@ methods :meth:`tkinter.Widget.cget` and :meth:`tkinter.Widget.configure`.
|
||||
Modify or inquire widget state. If *statespec* is specified, sets the
|
||||
widget state according to it and return a new *statespec* indicating
|
||||
which flags were changed. If *statespec* is not specified, returns
|
||||
the currently-enabled state flags.
|
||||
the currently enabled state flags.
|
||||
|
||||
*statespec* will usually be a list or a tuple.
|
||||
|
||||
@ -465,7 +465,7 @@ Notebook
|
||||
|
||||
Ttk Notebook widget manages a collection of windows and displays a single
|
||||
one at a time. Each child window is associated with a tab, which the user
|
||||
may select to change the currently-displayed window.
|
||||
may select to change the currently displayed window.
|
||||
|
||||
|
||||
Options
|
||||
@ -543,7 +543,7 @@ of the following forms:
|
||||
* An integer between zero and the number of tabs
|
||||
* The name of a child window
|
||||
* A positional specification of the form "@x,y", which identifies the tab
|
||||
* The literal string "current", which identifies the currently-selected tab
|
||||
* The literal string "current", which identifies the currently selected tab
|
||||
* The literal string "end", which returns the number of tabs (only valid for
|
||||
:meth:`Notebook.index`)
|
||||
|
||||
@ -613,7 +613,7 @@ ttk.Notebook
|
||||
Selects the specified *tab_id*.
|
||||
|
||||
The associated child window will be displayed, and the
|
||||
previously-selected window (if different) is unmapped. If *tab_id* is
|
||||
previously selected window (if different) is unmapped. If *tab_id* is
|
||||
omitted, returns the widget name of the currently selected pane.
|
||||
|
||||
|
||||
|
@ -78,7 +78,7 @@ annotations. These include:
|
||||
*Introducing* :data:`TypeVarTuple`
|
||||
* :pep:`647`: User-Defined Type Guards
|
||||
*Introducing* :data:`TypeGuard`
|
||||
* :pep:`655`: Marking individual TypedDict items as required or potentially-missing
|
||||
* :pep:`655`: Marking individual TypedDict items as required or potentially missing
|
||||
*Introducing* :data:`Required` and :data:`NotRequired`
|
||||
* :pep:`673`: Self type
|
||||
*Introducing* :data:`Self`
|
||||
@ -1034,7 +1034,7 @@ These can be used as types in annotations using ``[]``, each having a unique syn
|
||||
as either required or non-required respectively.
|
||||
|
||||
For more information, see :class:`TypedDict` and
|
||||
:pep:`655` ("Marking individual TypedDict items as required or potentially-missing").
|
||||
:pep:`655` ("Marking individual TypedDict items as required or potentially missing").
|
||||
|
||||
.. versionadded:: 3.11
|
||||
|
||||
|
@ -1279,7 +1279,7 @@ involved. For example, the :envvar:`http_proxy` environment variable is read to
|
||||
obtain the HTTP proxy's URL.
|
||||
|
||||
This example replaces the default :class:`ProxyHandler` with one that uses
|
||||
programmatically-supplied proxy URLs, and adds proxy authorization support with
|
||||
programmatically supplied proxy URLs, and adds proxy authorization support with
|
||||
:class:`ProxyBasicAuthHandler`. ::
|
||||
|
||||
proxy_handler = urllib.request.ProxyHandler({'http': 'http://www.example.com:3128/'})
|
||||
|
@ -211,7 +211,7 @@ The :mod:`uuid` module defines the following namespace identifiers for use with
|
||||
|
||||
.. data:: NAMESPACE_DNS
|
||||
|
||||
When this namespace is specified, the *name* string is a fully-qualified domain
|
||||
When this namespace is specified, the *name* string is a fully qualified domain
|
||||
name.
|
||||
|
||||
|
||||
|
@ -163,9 +163,9 @@ the disposition of the match. Each entry is a tuple of the form (*action*,
|
||||
category must be a subclass in order to match.
|
||||
|
||||
* *module* is a string containing a regular expression that the start of the
|
||||
fully-qualified module name must match, case-sensitively. In :option:`-W` and
|
||||
fully qualified module name must match, case-sensitively. In :option:`-W` and
|
||||
:envvar:`PYTHONWARNINGS`, *module* is a literal string that the
|
||||
fully-qualified module name must be equal to (case-sensitively), ignoring any
|
||||
fully qualified module name must be equal to (case-sensitively), ignoring any
|
||||
whitespace at the start or end of *module*.
|
||||
|
||||
* *lineno* is an integer that the line number where the warning occurred must
|
||||
|
@ -333,7 +333,7 @@ request. (E.g., using the :func:`shift_path_info` function from
|
||||
|
||||
.. method:: WSGIServer.get_app()
|
||||
|
||||
Returns the currently-set application callable.
|
||||
Returns the currently set application callable.
|
||||
|
||||
Normally, however, you do not need to use these additional methods, as
|
||||
:meth:`set_app` is normally called by :func:`make_server`, and the
|
||||
@ -642,7 +642,7 @@ input, output, and error streams.
|
||||
|
||||
.. method:: BaseHandler.setup_environ()
|
||||
|
||||
Set the :attr:`environ` attribute to a fully-populated WSGI environment. The
|
||||
Set the :attr:`environ` attribute to a fully populated WSGI environment. The
|
||||
default implementation uses all of the above methods and attributes, plus the
|
||||
:meth:`get_stdin`, :meth:`get_stderr`, and :meth:`add_cgi_vars` methods and the
|
||||
:attr:`wsgi_file_wrapper` attribute. It also inserts a ``SERVER_SOFTWARE`` key
|
||||
|
@ -95,7 +95,7 @@ quadratic blowup entity expansion
|
||||
entity expansion, too. Instead of nested entities it repeats one large entity
|
||||
with a couple of thousand chars over and over again. The attack isn't as
|
||||
efficient as the exponential case but it avoids triggering parser countermeasures
|
||||
that forbid deeply-nested entities.
|
||||
that forbid deeply nested entities.
|
||||
|
||||
external entity expansion
|
||||
Entity declarations can contain more than just text for replacement. They can
|
||||
|
@ -47,7 +47,7 @@ between conformable Python objects and XML on the wire.
|
||||
The following parameters govern the use of the returned proxy instance.
|
||||
If *allow_none* is true, the Python constant ``None`` will be translated into
|
||||
XML; the default behaviour is for ``None`` to raise a :exc:`TypeError`. This is
|
||||
a commonly-used extension to the XML-RPC specification, but isn't supported by
|
||||
a commonly used extension to the XML-RPC specification, but isn't supported by
|
||||
all clients and servers; see `http://ontosys.com/xml-rpc/extensions.php
|
||||
<https://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php>`_
|
||||
for a description.
|
||||
|
@ -265,7 +265,7 @@ Decompression objects support the following methods and attributes:
|
||||
A boolean indicating whether the end of the compressed data stream has been
|
||||
reached.
|
||||
|
||||
This makes it possible to distinguish between a properly-formed compressed
|
||||
This makes it possible to distinguish between a properly formed compressed
|
||||
stream, and an incomplete or truncated one.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
@ -1270,7 +1270,7 @@ Basic customization
|
||||
|
||||
Typical implementations create a new instance of the class by invoking the
|
||||
superclass's :meth:`__new__` method using ``super().__new__(cls[, ...])``
|
||||
with appropriate arguments and then modifying the newly-created instance
|
||||
with appropriate arguments and then modifying the newly created instance
|
||||
as necessary before returning it.
|
||||
|
||||
If :meth:`__new__` is invoked during object construction and it returns an
|
||||
@ -1560,7 +1560,7 @@ Basic customization
|
||||
predictable between repeated invocations of Python.
|
||||
|
||||
This is intended to provide protection against a denial-of-service caused
|
||||
by carefully-chosen inputs that exploit the worst case performance of a
|
||||
by carefully chosen inputs that exploit the worst case performance of a
|
||||
dict insertion, O(n\ :sup:`2`) complexity. See
|
||||
http://www.ocert.org/advisories/ocert-2011-003.html for details.
|
||||
|
||||
|
@ -541,7 +541,7 @@ the module.
|
||||
|
||||
.. attribute:: __name__
|
||||
|
||||
The ``__name__`` attribute must be set to the fully-qualified name of
|
||||
The ``__name__`` attribute must be set to the fully qualified name of
|
||||
the module. This name is used to uniquely identify the module in
|
||||
the import system.
|
||||
|
||||
|
@ -757,7 +757,7 @@ the final value of the whole string.
|
||||
|
||||
Top-level format specifiers may include nested replacement fields. These nested
|
||||
fields may include their own conversion fields and :ref:`format specifiers
|
||||
<formatspec>`, but may not include more deeply-nested replacement fields. The
|
||||
<formatspec>`, but may not include more deeply nested replacement fields. The
|
||||
:ref:`format specifier mini-language <formatspec>` is the same as that used by
|
||||
the :meth:`str.format` method.
|
||||
|
||||
|
@ -297,7 +297,7 @@ initial state. Therefore a class may define a special method named
|
||||
self.data = []
|
||||
|
||||
When a class defines an :meth:`__init__` method, class instantiation
|
||||
automatically invokes :meth:`__init__` for the newly-created class instance. So
|
||||
automatically invokes :meth:`__init__` for the newly created class instance. So
|
||||
in this example, a new, initialized instance can be obtained by::
|
||||
|
||||
x = MyClass()
|
||||
|
@ -189,7 +189,7 @@ notation. ::
|
||||
This is particularly useful in combination with the built-in function
|
||||
:func:`vars`, which returns a dictionary containing all local variables.
|
||||
|
||||
As an example, the following lines produce a tidily-aligned
|
||||
As an example, the following lines produce a tidily aligned
|
||||
set of columns giving integers and their squares and cubes::
|
||||
|
||||
>>> for x in range(1, 11):
|
||||
|
@ -368,7 +368,7 @@ Miscellaneous options
|
||||
between repeated invocations of Python.
|
||||
|
||||
Hash randomization is intended to provide protection against a
|
||||
denial-of-service caused by carefully-chosen inputs that exploit the worst
|
||||
denial-of-service caused by carefully chosen inputs that exploit the worst
|
||||
case performance of a dict construction, O(n\ :sup:`2`) complexity. See
|
||||
http://www.ocert.org/advisories/ocert-2011-003.html for details.
|
||||
|
||||
@ -464,7 +464,7 @@ Miscellaneous options
|
||||
whether the actual warning category of the message is a subclass of the
|
||||
specified warning category.
|
||||
|
||||
The *module* field matches the (fully-qualified) module name; this match is
|
||||
The *module* field matches the (fully qualified) module name; this match is
|
||||
case-sensitive.
|
||||
|
||||
The *lineno* field matches the line number, where zero matches all line
|
||||
|
@ -21,7 +21,7 @@ Python's development never completely stops between releases, and a steady flow
|
||||
of bug fixes and improvements are always being submitted. A host of minor fixes,
|
||||
a few optimizations, additional docstrings, and better error messages went into
|
||||
2.0; to list them all would be impossible, but they're certainly significant.
|
||||
Consult the publicly-available CVS logs if you want to see the full list. This
|
||||
Consult the publicly available CVS logs if you want to see the full list. This
|
||||
progress is due to the five developers working for PythonLabs are now getting
|
||||
paid to spend their days fixing bugs, and also due to the improved communication
|
||||
resulting from moving to SourceForge.
|
||||
|
@ -527,7 +527,7 @@ creates a :class:`LogRecord` instance that is sent to any number of different
|
||||
of filters, and each filter can cause the :class:`LogRecord` to be ignored or
|
||||
can modify the record before passing it along. When they're finally output,
|
||||
:class:`LogRecord` instances are converted to text by a :class:`Formatter`
|
||||
class. All of these classes can be replaced by your own specially-written
|
||||
class. All of these classes can be replaced by your own specially written
|
||||
classes.
|
||||
|
||||
With all of these features the :mod:`logging` package should provide enough
|
||||
|
@ -120,7 +120,7 @@ having the entire data set in memory at one time. List comprehensions don't fit
|
||||
into this picture very well because they produce a Python list object containing
|
||||
all of the items. This unavoidably pulls all of the objects into memory, which
|
||||
can be a problem if your data set is very large. When trying to write a
|
||||
functionally-styled program, it would be natural to write something like::
|
||||
functionally styled program, it would be natural to write something like::
|
||||
|
||||
links = [link for link in get_all_links() if not link.followed]
|
||||
for link in links:
|
||||
@ -918,7 +918,7 @@ Here are all of the changes that Python 2.4 makes to the core Python language.
|
||||
|
||||
(Contributed by Raymond Hettinger.)
|
||||
|
||||
* Encountering a failure while importing a module no longer leaves a partially-initialized
|
||||
* Encountering a failure while importing a module no longer leaves a partially initialized
|
||||
module object in ``sys.modules``. The incomplete module object left
|
||||
behind would fool further imports of the same module into succeeding, leading to
|
||||
confusing errors. (Fixed by Tim Peters.)
|
||||
@ -1541,7 +1541,7 @@ code:
|
||||
* The :mod:`tarfile` module now generates GNU-format tar files by default.
|
||||
|
||||
* Encountering a failure while importing a module no longer leaves a
|
||||
partially-initialized module object in ``sys.modules``.
|
||||
partially initialized module object in ``sys.modules``.
|
||||
|
||||
* :const:`None` is now a constant; code that binds a new value to the name
|
||||
``None`` is now a syntax error.
|
||||
|
@ -15,7 +15,7 @@ release schedule. Python 2.5 was released on September 19, 2006.
|
||||
|
||||
The changes in Python 2.5 are an interesting mix of language and library
|
||||
improvements. The library enhancements will be more important to Python's user
|
||||
community, I think, because several widely-useful packages were added. New
|
||||
community, I think, because several widely useful packages were added. New
|
||||
modules include ElementTree for XML processing (:mod:`xml.etree`),
|
||||
the SQLite database module (:mod:`sqlite`), and the :mod:`ctypes`
|
||||
module for calling C functions.
|
||||
@ -1293,7 +1293,7 @@ complete list of changes, or look through the SVN logs for all the details.
|
||||
received several enhancements and a number of bugfixes. You can now set the
|
||||
maximum size in bytes of a field by calling the
|
||||
``csv.field_size_limit(new_limit)`` function; omitting the *new_limit*
|
||||
argument will return the currently-set limit. The :class:`reader` class now has
|
||||
argument will return the currently set limit. The :class:`reader` class now has
|
||||
a :attr:`line_num` attribute that counts the number of physical lines read from
|
||||
the source; records can span multiple physical lines, so :attr:`line_num` is not
|
||||
the same as the number of records read.
|
||||
|
@ -523,7 +523,7 @@ PEP 370: Per-user ``site-packages`` Directory
|
||||
|
||||
When you run Python, the module search path ``sys.path`` usually
|
||||
includes a directory whose path ends in ``"site-packages"``. This
|
||||
directory is intended to hold locally-installed packages available to
|
||||
directory is intended to hold locally installed packages available to
|
||||
all users using a machine or a particular site installation.
|
||||
|
||||
Python 2.6 introduces a convention for user-specific site directories.
|
||||
@ -2460,7 +2460,7 @@ changes, or look through the Subversion logs for all the details.
|
||||
The function must take a filename and return true if the file
|
||||
should be excluded or false if it should be archived.
|
||||
The function is applied to both the name initially passed to :meth:`add`
|
||||
and to the names of files in recursively-added directories.
|
||||
and to the names of files in recursively added directories.
|
||||
|
||||
(All changes contributed by Lars Gustäbel).
|
||||
|
||||
@ -2513,7 +2513,7 @@ changes, or look through the Subversion logs for all the details.
|
||||
(Contributed by Brett Cannon.)
|
||||
|
||||
* The :mod:`textwrap` module can now preserve existing whitespace
|
||||
at the beginnings and ends of the newly-created lines
|
||||
at the beginnings and ends of the newly created lines
|
||||
by specifying ``drop_whitespace=False``
|
||||
as an argument::
|
||||
|
||||
|
@ -279,7 +279,7 @@ Comparing an :class:`~collections.OrderedDict` with a regular dictionary
|
||||
ignores the insertion order and just compares the keys and values.
|
||||
|
||||
How does the :class:`~collections.OrderedDict` work? It maintains a
|
||||
doubly-linked list of keys, appending new keys to the list as they're inserted.
|
||||
doubly linked list of keys, appending new keys to the list as they're inserted.
|
||||
A secondary dictionary maps keys to their corresponding list node, so
|
||||
deletion doesn't have to traverse the entire linked list and therefore
|
||||
remains O(1).
|
||||
@ -1968,7 +1968,7 @@ GvR worked on merging them into Python's version of :mod:`unittest`.
|
||||
|
||||
* :meth:`~unittest.TestCase.assertAlmostEqual` and :meth:`~unittest.TestCase.assertNotAlmostEqual` test
|
||||
whether *first* and *second* are approximately equal. This method
|
||||
can either round their difference to an optionally-specified number
|
||||
can either round their difference to an optionally specified number
|
||||
of *places* (the default is 7) and compare it to zero, or require
|
||||
the difference to be smaller than a supplied *delta* value.
|
||||
|
||||
@ -2333,7 +2333,7 @@ Port-Specific Changes: Windows
|
||||
|
||||
* The :mod:`_winreg` module for accessing the registry now implements
|
||||
the :func:`~_winreg.CreateKeyEx` and :func:`~_winreg.DeleteKeyEx`
|
||||
functions, extended versions of previously-supported functions that
|
||||
functions, extended versions of previously supported functions that
|
||||
take several extra arguments. The :func:`~_winreg.DisableReflectionKey`,
|
||||
:func:`~_winreg.EnableReflectionKey`, and :func:`~_winreg.QueryReflectionKey`
|
||||
were also tested and documented.
|
||||
|
@ -663,7 +663,7 @@ Some other changes to standard library modules, not covered by
|
||||
:data:`string.ascii_letters` etc. instead. (The reason for the
|
||||
removal is that :data:`string.letters` and friends had
|
||||
locale-specific behavior, which is a bad idea for such
|
||||
attractively-named global "constants".)
|
||||
attractively named global "constants".)
|
||||
|
||||
* Renamed module :mod:`__builtin__` to :mod:`builtins` (removing the
|
||||
underscores, adding an 's'). The :data:`__builtins__` variable
|
||||
|
@ -75,7 +75,7 @@ New syntax features:
|
||||
New typing features:
|
||||
|
||||
* :pep:`646`: Variadic generics.
|
||||
* :pep:`655`: Marking individual TypedDict items as required or potentially-missing.
|
||||
* :pep:`655`: Marking individual TypedDict items as required or potentially missing.
|
||||
* :pep:`673`: ``Self`` type.
|
||||
* :pep:`675`: Arbitrary literal string type.
|
||||
|
||||
|
@ -101,7 +101,7 @@ PEP 405: Virtual Environments
|
||||
|
||||
Virtual environments help create separate Python setups while sharing a
|
||||
system-wide base install, for ease of maintenance. Virtual environments
|
||||
have their own set of private site packages (i.e. locally-installed
|
||||
have their own set of private site packages (i.e. locally installed
|
||||
libraries), and are optionally segregated from the system-wide site
|
||||
packages. Their concept and implementation are inspired by the popular
|
||||
``virtualenv`` third-party package, but benefit from tighter integration
|
||||
@ -898,7 +898,7 @@ an IP address associated with a specific IP subnet).
|
||||
lzma
|
||||
----
|
||||
|
||||
The newly-added :mod:`lzma` module provides data compression and decompression
|
||||
The newly added :mod:`lzma` module provides data compression and decompression
|
||||
using the LZMA algorithm, including support for the ``.xz`` and ``.lzma``
|
||||
file formats.
|
||||
|
||||
@ -1096,7 +1096,7 @@ decimal
|
||||
C-module and libmpdec written by Stefan Krah.
|
||||
|
||||
The new C version of the decimal module integrates the high speed libmpdec
|
||||
library for arbitrary precision correctly-rounded decimal floating point
|
||||
library for arbitrary precision correctly rounded decimal floating point
|
||||
arithmetic. libmpdec conforms to IBM's General Decimal Arithmetic Specification.
|
||||
|
||||
Performance gains range from 10x for database applications to 100x for
|
||||
@ -1158,8 +1158,8 @@ API changes
|
||||
in order to obtain a rounded or inexact value.
|
||||
|
||||
|
||||
* The power function in decimal.py is always correctly-rounded. In the
|
||||
C version, it is defined in terms of the correctly-rounded
|
||||
* The power function in decimal.py is always correctly rounded. In the
|
||||
C version, it is defined in terms of the correctly rounded
|
||||
:meth:`~decimal.Decimal.exp` and :meth:`~decimal.Decimal.ln` functions,
|
||||
but the final result is only "almost always correctly rounded".
|
||||
|
||||
@ -2137,7 +2137,7 @@ zlib
|
||||
----
|
||||
|
||||
New attribute :attr:`zlib.Decompress.eof` makes it possible to distinguish
|
||||
between a properly-formed compressed stream and an incomplete or truncated one.
|
||||
between a properly formed compressed stream and an incomplete or truncated one.
|
||||
(Contributed by Nadeem Vawda in :issue:`12646`.)
|
||||
|
||||
New attribute :attr:`zlib.ZLIB_RUNTIME_VERSION` reports the version string of
|
||||
|
@ -1659,7 +1659,7 @@ The :class:`~unittest.TestCase` class has a new method,
|
||||
:keyword:`with` block becomes a "sub-test". This context manager allows a test
|
||||
method to dynamically generate subtests by, say, calling the ``subTest``
|
||||
context manager inside a loop. A single test method can thereby produce an
|
||||
indefinite number of separately-identified and separately-counted tests, all of
|
||||
indefinite number of separately identified and separately counted tests, all of
|
||||
which will run even if one or more of them fail. For example::
|
||||
|
||||
class NumbersTest(unittest.TestCase):
|
||||
@ -2056,7 +2056,7 @@ Significant Optimizations
|
||||
``malloc`` in ``obmalloc``. Artificial benchmarks show about a 3% memory
|
||||
savings.
|
||||
|
||||
* :func:`os.urandom` now uses a lazily-opened persistent file descriptor
|
||||
* :func:`os.urandom` now uses a lazily opened persistent file descriptor
|
||||
so as to avoid using many file descriptors when run in parallel from
|
||||
multiple threads. (Contributed by Antoine Pitrou in :issue:`18756`.)
|
||||
|
||||
|
@ -291,7 +291,7 @@ PEP 539: New C API for Thread-Local Storage
|
||||
While Python provides a C API for thread-local storage support; the existing
|
||||
:ref:`Thread Local Storage (TLS) API <thread-local-storage-api>` has used
|
||||
:c:type:`int` to represent TLS keys across all platforms. This has not
|
||||
generally been a problem for officially-support platforms, but that is neither
|
||||
generally been a problem for officially support platforms, but that is neither
|
||||
POSIX-compliant, nor portable in any practical sense.
|
||||
|
||||
:pep:`539` changes this by providing a new :ref:`Thread Specific Storage (TSS)
|
||||
@ -1175,7 +1175,7 @@ of :func:`os.writev` and :func:`os.pwrite`). (Contributed by Pablo Galindo in
|
||||
:issue:`31368`.)
|
||||
|
||||
The mode argument of :func:`os.makedirs` no longer affects the file
|
||||
permission bits of newly-created intermediate-level directories.
|
||||
permission bits of newly created intermediate-level directories.
|
||||
(Contributed by Serhiy Storchaka in :issue:`19930`.)
|
||||
|
||||
:func:`os.dup2` now returns the new file descriptor. Previously, ``None``
|
||||
@ -2296,7 +2296,7 @@ Changes in the Python API
|
||||
(Contributed by Serhiy Storchaka in :issue:`29192`.)
|
||||
|
||||
* The *mode* argument of :func:`os.makedirs` no longer affects the file
|
||||
permission bits of newly-created intermediate-level directories.
|
||||
permission bits of newly created intermediate-level directories.
|
||||
To set their file permission bits you can set the umask before invoking
|
||||
``makedirs()``.
|
||||
(Contributed by Serhiy Storchaka in :issue:`19930`.)
|
||||
|
@ -763,7 +763,7 @@ as a positional-only argument.
|
||||
.. nonce: qLkNh8
|
||||
.. section: Library
|
||||
|
||||
Enum: fix regression involving inheriting a multiply-inherited enum
|
||||
Enum: fix regression involving inheriting a multiply inherited enum
|
||||
|
||||
..
|
||||
|
||||
|
@ -446,7 +446,7 @@ In ``importlib.metadata``: - ``EntryPoint`` objects now expose a ``.dist``
|
||||
object referencing the ``Distribution`` when constructed from a
|
||||
``Distribution``. - Add support for package discovery under package
|
||||
normalization rules. - The object returned by ``metadata()`` now has a
|
||||
formally-defined protocol called ``PackageMetadata`` with declared support
|
||||
formally defined protocol called ``PackageMetadata`` with declared support
|
||||
for the ``.get_all()`` method. - Synced with importlib_metadata 3.3.
|
||||
|
||||
..
|
||||
|
@ -694,7 +694,7 @@ removed in the future.
|
||||
.. section: Library
|
||||
|
||||
:mod:`argparse` raises :exc:`ValueError` with clear message when trying to
|
||||
render usage for an empty mutually-exclusive group. Previously it raised a
|
||||
render usage for an empty mutually exclusive group. Previously it raised a
|
||||
cryptic :exc:`IndexError`.
|
||||
|
||||
..
|
||||
|
@ -109,7 +109,7 @@ methods are called only on objects of the correct type.
|
||||
.. nonce: 2PpaIN
|
||||
.. section: Core and Builtins
|
||||
|
||||
Deoptimize statically-allocated code objects during ``Py_FINALIZE()`` so
|
||||
Deoptimize statically allocated code objects during ``Py_FINALIZE()`` so
|
||||
that future ``_PyCode_Quicken`` calls always start with unquickened code.
|
||||
|
||||
..
|
||||
|
@ -3149,7 +3149,7 @@ they are finished in multiprocessing.Pool.
|
||||
.. section: Library
|
||||
|
||||
The mode argument of os.makedirs() no longer affects the file permission
|
||||
bits of newly-created intermediate-level directories.
|
||||
bits of newly created intermediate-level directories.
|
||||
|
||||
..
|
||||
|
||||
|
@ -361,7 +361,7 @@ the "n" formatter.
|
||||
.. nonce: gjm1LO
|
||||
.. section: Core and Builtins
|
||||
|
||||
Fix a possible segfault involving a newly-created coroutine. Patch by
|
||||
Fix a possible segfault involving a newly created coroutine. Patch by
|
||||
Zackery Spytz.
|
||||
|
||||
..
|
||||
|
@ -356,7 +356,7 @@ Add *headers* optional keyword-only parameter to
|
||||
.. section: Library
|
||||
|
||||
Fix C implementation of pickle.loads to use importlib's locking mechanisms,
|
||||
and thereby avoid using partially-loaded modules. Patch by Tim Burgess.
|
||||
and thereby avoid using partially loaded modules. Patch by Tim Burgess.
|
||||
|
||||
..
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user