Fix typos in various PEPs (#1111)
This commit is contained in:
parent
f9cecb64b8
commit
e54097d3c4
|
@ -265,7 +265,7 @@ Open items -- completed/fixed
|
|||
Deal with buffering problem with SocketServer
|
||||
|
||||
[04-Sep-2000 tim: done; installer runs; w9xpopen not an issue]
|
||||
[01-Sep-2000 tim: make a prerelease availabe]
|
||||
[01-Sep-2000 tim: make a prerelease available]
|
||||
Windows ME: Don't know anything about it. Will the installer
|
||||
even run? Does it need the w9xpopen hack?
|
||||
|
||||
|
|
|
@ -84,7 +84,7 @@ Now, there is two thing the models promises for the field operations
|
|||
- All field rules are true, except that for not-``isexact()`` numbers,
|
||||
they might be only approximately true.
|
||||
|
||||
One consequence of these two rules is that all exact calcutions
|
||||
One consequence of these two rules is that all exact calculations
|
||||
are done as (complex) rationals: since the field laws must hold,
|
||||
then ::
|
||||
|
||||
|
|
|
@ -633,7 +633,7 @@ to be no good solution here.
|
|||
|
||||
It's also dubious how useful it is to support ``__findattr__`` both
|
||||
for getting and for setting attributes -- ``__setattr__`` gets called
|
||||
in all cases alrady.
|
||||
in all cases already.
|
||||
|
||||
The examples can all be implemented using ``__getattr__`` if care is
|
||||
taken not to store instance variables under their own names.
|
||||
|
|
|
@ -55,7 +55,7 @@ will consist of the following fields:
|
|||
- ``pkginfo`` (optional) -- The file containing the distribution
|
||||
meta-data (as specified in PEP 241 [1]_). Note that if this is
|
||||
not included, the distribution file is expected to be in ``.tar``
|
||||
format (gzipped and bzipped compreesed are allowed) or ``.zip``
|
||||
format (gzipped and bzipped compressed are allowed) or ``.zip``
|
||||
format, with a ``PKG-INFO`` file in the top-level directory it
|
||||
extracts (``package-1.00/PKG-INFO``).
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@ type names are available to be consistently used to refer to the type
|
|||
object.
|
||||
|
||||
Most types are accessible as either builtins or in the new module but
|
||||
some types such as traceback and generator are only accssible through
|
||||
some types such as traceback and generator are only accessible through
|
||||
the types module under names which do not match the type name. This
|
||||
PEP provides a uniform way to access all basic types under a single
|
||||
set of names.
|
||||
|
|
|
@ -131,7 +131,7 @@ These functions aren't supposed to be called directly, they are
|
|||
called through convenience functions declared in
|
||||
Include/abstract.h::
|
||||
|
||||
int PyObject_AquireLockedReadBuffer(PyObject *obj,
|
||||
int PyObject_AcquireLockedReadBuffer(PyObject *obj,
|
||||
const void **buffer,
|
||||
size_t *buffer_len);
|
||||
|
||||
|
|
|
@ -102,7 +102,7 @@ After unprecedented community response (very good arguments were
|
|||
made both pro and con) this PEP has been revised with the help of
|
||||
Raymond Hettinger. Without going through a complete revision
|
||||
history, the main changes are a different proposed syntax, an
|
||||
overview of proposed alternatives, the state of the curent
|
||||
overview of proposed alternatives, the state of the current
|
||||
discussion, and a discussion of short-circuit behavior.
|
||||
|
||||
Following the discussion, a vote was held. While there was an overall
|
||||
|
|
|
@ -36,7 +36,7 @@ Adding ``__copy__`` methods to existing iterators will change the
|
|||
behavior under ``tee()``. Currently, the copied iterators remain
|
||||
tied to the original iterator. If the original advances, then
|
||||
so do all of the copies. Good practice is to overwrite the
|
||||
original so that anamolies don't result: ``a,b=tee(a)``.
|
||||
original so that anomalies don't result: ``a,b=tee(a)``.
|
||||
Code that doesn't follow that practice may observe a semantic
|
||||
change if a ``__copy__`` method is added to an iterator.
|
||||
|
||||
|
|
|
@ -569,7 +569,7 @@ API for Py2.4. Several ideas contributed to the thought process:
|
|||
|
||||
- While theoretically nice, real world use cases for interactions between floats
|
||||
and decimals are lacking. Java included float/decimal conversions to handle
|
||||
an obscure case where calculations are best performed in decimal eventhough
|
||||
an obscure case where calculations are best performed in decimal even though
|
||||
a legacy data structure requires the inputs and outputs to be stored in
|
||||
binary floating point.
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ variable for distutils.
|
|||
The user site directory is added before the system site directories
|
||||
but after Python's search paths and ``PYTHONPATH``. This setup allows
|
||||
the user to install a different version of a package than the system
|
||||
administrator but it prevents the user from accidently overwriting a
|
||||
administrator but it prevents the user from accidentally overwriting a
|
||||
stdlib module. Stdlib modules can still be overwritten with
|
||||
``PYTHONPATH``.
|
||||
|
||||
|
|
|
@ -157,7 +157,7 @@ ability is nonetheless considered worthwhile.
|
|||
|
||||
On Unix, the user can control which specific version of Python is used
|
||||
by adjusting the links in /usr/bin to point to the desired version. As
|
||||
the launcher on Windows will not use Windows links, cutomization options
|
||||
the launcher on Windows will not use Windows links, customization options
|
||||
(exposed via both environment variables and INI files) will be used to
|
||||
override the semantics for determining what version of Python will be
|
||||
used. For example, while a shebang line of "/usr/bin/python2" will
|
||||
|
|
|
@ -179,7 +179,7 @@ the heavy lifting:
|
|||
* comprehensions, generator expressions, map(), filter()
|
||||
* key arguments to sorted(), min(), max()
|
||||
* partial function application
|
||||
* provision of callbacks (e.g. for weak references or aysnchronous IO)
|
||||
* provision of callbacks (e.g. for weak references or asynchronous IO)
|
||||
* array broadcast operations in NumPy
|
||||
|
||||
However, adopting Ruby's block syntax directly won't work for Python, since
|
||||
|
|
|
@ -52,7 +52,7 @@ mailbox with the mailbox module, etc.
|
|||
An arbitrary resolution is preferred over a fixed resolution (like nanosecond)
|
||||
to not have to change the API when a better resolution is required. For
|
||||
example, the NTP protocol uses fractions of 2\ :sup:`32` seconds
|
||||
(approximatively 2.3 × 10\ :sup:`-10` second), whereas the NTP protocol version
|
||||
(approximately 2.3 × 10\ :sup:`-10` second), whereas the NTP protocol version
|
||||
4 uses fractions of 2\ :sup:`64` seconds (5.4 × 10\ :sup:`-20` second).
|
||||
|
||||
.. note::
|
||||
|
|
|
@ -277,10 +277,10 @@ New collections
|
|||
^^^^^^^^^^^^^^^
|
||||
|
||||
* ``all_timezones`` is the exhaustive list of the time zone names that can
|
||||
be used, listed alphabethically.
|
||||
be used, listed alphabetically.
|
||||
|
||||
* ``common_timezones`` is a list of useful, current time zones, listed
|
||||
alphabethically.
|
||||
alphabetically.
|
||||
|
||||
|
||||
The ``tzdata-update``-package
|
||||
|
|
|
@ -260,7 +260,7 @@ Add a new optional parameter *cloexec* on functions creating file
|
|||
descriptors. The default value of the *cloexec* parameter is ``False``,
|
||||
and this default cannot be changed. File descriptor inheritance enabled by
|
||||
default is also the default on POSIX and on Windows. This alternative is
|
||||
the most convervative option.
|
||||
the most conservative option.
|
||||
|
||||
This option does not solve issues listed in the `Rationale`_
|
||||
section, it only provides a helper to fix them. All functions creating
|
||||
|
@ -704,7 +704,7 @@ Python issues:
|
|||
|
||||
Other languages:
|
||||
|
||||
* Perl sets the close-on-exec flag on newly created file decriptor if
|
||||
* Perl sets the close-on-exec flag on newly created file descriptor if
|
||||
their number is greater than ``$SYSTEM_FD_MAX`` (``$^F``).
|
||||
See `$SYSTEM_FD_MAX documentation
|
||||
<http://perldoc.perl.org/perlvar.html#%24SYSTEM_FD_MAX>`_. Perl does
|
||||
|
|
|
@ -335,7 +335,7 @@ that the middleware wraps may in fact be another middleware component
|
|||
wrapping another application, and so on, creating what is referred to
|
||||
as a "middleware stack".
|
||||
|
||||
A middleware must support asychronous execution if possible or fall
|
||||
A middleware must support asynchronous execution if possible or fall
|
||||
back to disabling itself.
|
||||
|
||||
Here a middleware that changes the ``HTTP_HOST`` key if an ``X-Host``
|
||||
|
@ -354,7 +354,7 @@ header exists and adds a comment to all html responses::
|
|||
if not hasattr(app_response, '__call__'):
|
||||
return filter_func(*app_response)
|
||||
|
||||
# asychronous response. filter when results are ready
|
||||
# asynchronous response. filter when results are ready
|
||||
def polling_function():
|
||||
rv = app_response()
|
||||
if rv is not None:
|
||||
|
|
|
@ -243,7 +243,7 @@ TUF is designed to address these attacks, and others, by adding signed metadata
|
|||
referencing the metadata files during the update procedure. Repository files
|
||||
are verified against the information included in the metadata before they are
|
||||
handed off to the software update system. The framework also provides
|
||||
multi-signature trust, explicit and implicit revocation of cryptograhic keys,
|
||||
multi-signature trust, explicit and implicit revocation of cryptographic keys,
|
||||
responsibility separation of the metadata, and minimizes key risk. For a full
|
||||
list and outline of the repository attacks and software updater weaknesses
|
||||
addressed by TUF, see Appendix A.
|
||||
|
|
|
@ -401,7 +401,7 @@ Pros
|
|||
|
||||
Cons
|
||||
''''
|
||||
- Apparenty complex and wasteful;
|
||||
- Apparently complex and wasteful;
|
||||
- Degeneracy in notation (e.g. ``a[Z=3]`` and ``a[{"Z":3}]`` are equivalent and
|
||||
indistinguishable notations at the ``__[get|set|del]item__`` level).
|
||||
This behavior may or may not be acceptable.
|
||||
|
|
|
@ -651,7 +651,7 @@ attacks, or metadata inconsistency attacks.
|
|||
+-------------------+-------------------+-----------------------+-----------------------+
|
||||
| snapshot | NO | NO | NO |
|
||||
| | timestamp and | timestamp needs to | timestamp needs to |
|
||||
| | targets or any of | coorperate | cooperate |
|
||||
| | targets or any of | cooperate | cooperate |
|
||||
| | the delegated | | |
|
||||
| | roles need to | | |
|
||||
| | cooperate | | |
|
||||
|
|
|
@ -117,7 +117,7 @@ multiplication, comparisons, and subtraction. However, the implementation
|
|||
in the math module is written in C, and thus can not (easily) use python's
|
||||
duck typing. Rather, the values passed into the funciton will be converted
|
||||
to the float type before the calculation is performed. Passing in types
|
||||
(or values) that cannot be converted to floats will raise an appropirate
|
||||
(or values) that cannot be converted to floats will raise an appropriate
|
||||
Exception (TypeError, ValueError, or OverflowError).
|
||||
|
||||
The code will be tested to accommodate at least some values of these types:
|
||||
|
|
|
@ -78,7 +78,7 @@ additional level of indirection)::
|
|||
def ensure_repeatable():
|
||||
"""Switch to using random.Random() for the module level APIs
|
||||
|
||||
This switches the default RNG instance from the crytographically
|
||||
This switches the default RNG instance from the cryptographically
|
||||
secure random.SystemRandom() to the deterministic random.Random(),
|
||||
enabling the seed(), getstate() and setstate() operations. This means
|
||||
a particular random scenario can be replayed later by providing the
|
||||
|
|
|
@ -38,7 +38,7 @@ class NoneCoalesceIfBlockVisitor(ast.NodeVisitor):
|
|||
... else:
|
||||
... self.b = c
|
||||
|
||||
...where `a` is a name and other characters represent any abitrary
|
||||
...where `a` is a name and other characters represent any arbitrary
|
||||
expression.
|
||||
|
||||
In the two latter forms, the search criterion is an assignment of `a`
|
||||
|
@ -144,7 +144,7 @@ class NoneCoalesceTernaryVisitor(ast.NodeVisitor):
|
|||
>>> a if a is not None else b
|
||||
>>> b if a is None else a
|
||||
|
||||
...where a is an identifier and b is an abitrary expression.
|
||||
...where a is an identifier and b is an arbitrary expression.
|
||||
'''
|
||||
|
||||
def __init__(self, file_, callback):
|
||||
|
@ -294,7 +294,7 @@ class SafeNavTernaryVisitor(ast.NodeVisitor):
|
|||
>>> a.foo if a is not None else b
|
||||
>>> b if a is None else a.foo
|
||||
|
||||
...where `a` is an identifier, `b` is an abitrary expression, and `foo` is
|
||||
...where `a` is an identifier, `b` is an arbitrary expression, and `foo` is
|
||||
an attribute, index, or function invocation.
|
||||
'''
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ PyPy has a ``cpyext`` module which emulates the Python C API but it has
|
|||
worse performances than CPython and does not support the full Python C
|
||||
API.
|
||||
|
||||
New features are first developped in CPython. In January 2016, the
|
||||
New features are first developed in CPython. In January 2016, the
|
||||
latest CPython stable version is 3.5, whereas PyPy only supports Python
|
||||
2.7 and 3.2, and Pyston only supports Python 2.7.
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ importlib hooks. If a feature becomes useful, it should be directly part
|
|||
of Python, instead of depending on an third party Python module.
|
||||
|
||||
Finally, this PEP was driven was the FAT Python optimization project
|
||||
which was abandonned in 2016, since it was not possible to show any
|
||||
which was abandoned in 2016, since it was not possible to show any
|
||||
significant speedup, but also because of the lack of time to implement
|
||||
the most advanced and complex optimizations.
|
||||
|
||||
|
|
|
@ -175,7 +175,7 @@ The company name ``PyLauncher`` is reserved for the PEP 397 launcher
|
|||
(``py.exe``). It does not follow this convention and should be ignored by tools.
|
||||
|
||||
If a string value named ``DisplayName`` exists, it should be used to identify
|
||||
the environment manufacturer/developer/destributor to users. Otherwise, the name
|
||||
the environment manufacturer/developer/distributor to users. Otherwise, the name
|
||||
of the key should be used. (For ``PythonCore``, the default display name is
|
||||
"Python Software Foundation".)
|
||||
|
||||
|
|
|
@ -189,7 +189,7 @@ The addition of ``os.fspath()``, the updates to
|
|||
``pathlib.PurePath`` provide the semantics necessary to
|
||||
get the path representation one prefers. For a path object,
|
||||
``pathlib.PurePath``/``Path`` can be used. To obtain the ``str`` or
|
||||
``bytes`` representation without any coersion, then ``os.fspath()``
|
||||
``bytes`` representation without any coercion, then ``os.fspath()``
|
||||
can be used. If a ``str`` is desired and the encoding of ``bytes``
|
||||
should be assumed to be the default file system encoding, then
|
||||
``os.fsdecode()`` should be used. If a ``bytes`` representation is
|
||||
|
|
|
@ -409,7 +409,7 @@ Proposition
|
|||
<https://www.python.org/dev/peps/pep-0522/>`_.
|
||||
|
||||
Python should not decide for the developer how to handle `The bug`_:
|
||||
raising immediatly a ``BlockingIOError`` if ``os.urandom()`` is going to
|
||||
raising immediately a ``BlockingIOError`` if ``os.urandom()`` is going to
|
||||
block allows developers to choose how to handle this case:
|
||||
|
||||
* catch the exception and falls back to a non-secure entropy source:
|
||||
|
|
|
@ -159,7 +159,7 @@ File Extensions
|
|||
Currently ``sdist`` supports a wide variety of file extensions like ``.tar.gz``,
|
||||
``.tar``, ``.tar.bz2``, ``.tar.xz``, ``.zip``, ``.tar.Z``, ``.tgz``, and
|
||||
``.tbz``. However, of those the only extensions which get anything more than
|
||||
negligable usage is ``.tar.gz`` with 444,338 sdists currently, ``.zip`` with
|
||||
negligible usage is ``.tar.gz`` with 444,338 sdists currently, ``.zip`` with
|
||||
58,774 sdists currently, and ``.tar.bz2`` with 3,265 sdists currently.
|
||||
|
||||
Having multiple formats accepted requires tooling both within PyPI and outside
|
||||
|
|
|
@ -170,7 +170,7 @@ idiom (``with`` block + ``for`` loop) and merging them together into a
|
|||
fancier ``for``. This may seem non-orthogonal, but makes sense when
|
||||
you consider that the existence of generators means that ``with``
|
||||
blocks actually depend on iterator cleanup to work reliably, plus
|
||||
experience showing that iterator cleanup is often a desireable feature
|
||||
experience showing that iterator cleanup is often a desirable feature
|
||||
in its own right.
|
||||
|
||||
|
||||
|
|
|
@ -100,7 +100,7 @@ Our implementation faces two challenges:
|
|||
be passed in as a "self" argument to all module-level functions.
|
||||
|
||||
Both challenges can be solved with the same approach: we define a new
|
||||
"fast subclass" flag that means "This object is a desciptor, and it
|
||||
"fast subclass" flag that means "This object is a descriptor, and it
|
||||
should be honored directly when this object is looked up as an
|
||||
attribute of an instance". So far this flag is only set on two
|
||||
types: ``property`` and ``collections.abc.InstanceDescriptor``.
|
||||
|
|
|
@ -1109,7 +1109,7 @@ Resetting __main__
|
|||
As proposed, every call to ``Interpreter.run()`` will execute in the
|
||||
namespace of the interpreter's existing ``__main__`` module. This means
|
||||
that data persists there between ``run()`` calls. Sometimes this isn't
|
||||
desireable and you want to execute in a fresh ``__main__``. Also,
|
||||
desirable and you want to execute in a fresh ``__main__``. Also,
|
||||
you don't necessarily want to leak objects there that you aren't using
|
||||
any more.
|
||||
|
||||
|
@ -1224,7 +1224,7 @@ Buffering
|
|||
---------
|
||||
|
||||
The proposed channels are unbuffered. This simplifies the API and
|
||||
implementation. If buffering is desireable we can add it later.
|
||||
implementation. If buffering is desirable we can add it later.
|
||||
|
||||
Return a lock from send()
|
||||
-------------------------
|
||||
|
@ -1351,7 +1351,7 @@ Rejected possible solutions:
|
|||
* return the exception (or its proxy) from ``run()`` instead of
|
||||
raising it
|
||||
* return a result object (like ``subprocess`` does) [result-object]_
|
||||
(unecessary complexity?)
|
||||
(unnecessary complexity?)
|
||||
* throw the exception away and expect users to deal with unhandled
|
||||
exceptions explicitly in the script they pass to ``run()``
|
||||
(they can pass error info out via channels); with threads you have
|
||||
|
|
|
@ -268,13 +268,13 @@ and live inside the ``gc`` module, unless otherwise noted:
|
|||
"""
|
||||
Allocate a GC-enabled object.
|
||||
"""
|
||||
# Update allocation statistics (same code as currently, omitted for brievity)
|
||||
# Update allocation statistics (same code as currently, omitted for brevity)
|
||||
if is_implicit_gc_desired():
|
||||
if gc_is_threaded:
|
||||
schedule_gc_request()
|
||||
else:
|
||||
lock_and_collect()
|
||||
# Go ahead with allocation (same code as currently, omitted for brievity)
|
||||
# Go ahead with allocation (same code as currently, omitted for brevity)
|
||||
|
||||
|
||||
def gc_thread(interp_state):
|
||||
|
|
|
@ -30,7 +30,7 @@ This fixes one of the remaining roadblocks for adoption of PEP 3121 (Extension
|
|||
module initialization and finalization) and PEP 489
|
||||
(Multi-phase extension module initialization).
|
||||
|
||||
Additionaly, support for easier creation of immutable exception classes is added.
|
||||
Additionally, support for easier creation of immutable exception classes is added.
|
||||
This removes the need for keeping per-module state if it would only be used
|
||||
for exception classes.
|
||||
|
||||
|
@ -117,7 +117,7 @@ get the type object corresponding to the appropriate module.
|
|||
In short, heap types are "viral" – anything that “touches” them must itself be
|
||||
a heap type.
|
||||
|
||||
Curently, most exception types, apart from the ones in ``builtins``, are
|
||||
Currently, most exception types, apart from the ones in ``builtins``, are
|
||||
heap types. This is likely simply because there is a convenient way
|
||||
to create them: ``PyErr_NewException``.
|
||||
Heap types generally have a mutable ``__dict__``.
|
||||
|
|
|
@ -477,7 +477,7 @@ An important consequence is that such functions by default
|
|||
do not become methods when used as attribute
|
||||
(``base_function.__get__`` only does that if ``m_self`` was ``NULL``).
|
||||
One could consider this a bug, but this was done for backwards compatibility reasons:
|
||||
in an initial post on python-ideas [#proposal]_ the concensus was to keep this
|
||||
in an initial post on python-ideas [#proposal]_ the consensus was to keep this
|
||||
misfeature of built-in functions.
|
||||
|
||||
However, to allow this anyway for specific or newly implemented
|
||||
|
|
|
@ -23,7 +23,7 @@ A small improvement in the performance of existing code is expected.
|
|||
Motivation
|
||||
==========
|
||||
|
||||
Currently third-party module authors face a dilemna when implementing
|
||||
Currently third-party module authors face a dilemma when implementing
|
||||
functions in C. Either they can use one of the pre-existing built-in function
|
||||
or method classes or implement their own custom class in C.
|
||||
The first choice causes them to lose the ability to access the internals of the callable object.
|
||||
|
|
|
@ -537,7 +537,7 @@ they enable defenders to integrate Python into their environment in ways
|
|||
that are currently not possible.
|
||||
|
||||
Since audit hooks have the ability to safely prevent an operation
|
||||
occuring, this feature does enable the ability to provide some level of
|
||||
occurring, this feature does enable the ability to provide some level of
|
||||
sandboxing. In most cases, however, the intention is to enable logging
|
||||
rather than creating a sandbox.
|
||||
|
||||
|
|
10
pep-0587.rst
10
pep-0587.rst
|
@ -605,7 +605,7 @@ configuration, and then override some parameters::
|
|||
goto done;
|
||||
}
|
||||
|
||||
/* Set the program name before reading the configuraton
|
||||
/* Set the program name before reading the configuration
|
||||
(decode byte string from the locale encoding).
|
||||
|
||||
Implicitly preinitialize Python. */
|
||||
|
@ -1013,7 +1013,7 @@ Variable Field
|
|||
``Py_UTF8Mode`` ``utf8_mode``
|
||||
======================================== ================================
|
||||
|
||||
(NOT) means that the ``PyPreConfig`` value is the oposite of the global
|
||||
(NOT) means that the ``PyPreConfig`` value is the opposite of the global
|
||||
configuration variable value. ``Py_LegacyWindowsFSEncodingFlag`` is only
|
||||
available on Windows.
|
||||
|
||||
|
@ -1044,7 +1044,7 @@ Variable Field
|
|||
``_Py_HasFileSystemDefaultEncodeErrors`` ``filesystem_errors``
|
||||
======================================== ================================
|
||||
|
||||
(NOT) means that the ``PyConfig`` value is the oposite of the global
|
||||
(NOT) means that the ``PyConfig`` value is the opposite of the global
|
||||
configuration variable value. ``Py_LegacyWindowsStdioFlag`` is only
|
||||
available on Windows.
|
||||
|
||||
|
@ -1165,7 +1165,7 @@ Variable ``PyConfig`` field
|
|||
specific to Windows.
|
||||
|
||||
|
||||
Default Python Configugration
|
||||
Default Python Configuration
|
||||
-----------------------------
|
||||
|
||||
``PyPreConfig_InitPythonConfig()``:
|
||||
|
@ -1235,7 +1235,7 @@ Default Python Configugration
|
|||
* ``_install_importlib`` = 1
|
||||
|
||||
|
||||
Default Isolated Configugration
|
||||
Default Isolated Configuration
|
||||
-------------------------------
|
||||
|
||||
``PyPreConfig_InitIsolatedConfig()``:
|
||||
|
|
|
@ -286,7 +286,7 @@ Other rejected approaches
|
|||
|
||||
A longer, 6 argument, form combining both the vector and optional tuple and dictionary arguments was considered.
|
||||
However, it was found that the code to convert between it and the old ``tp_call`` form was overly cumbersome and inefficient.
|
||||
Also, since only 4 arguments are passed in registers on x64 Windows, the two extra arguments would have non-neglible costs.
|
||||
Also, since only 4 arguments are passed in registers on x64 Windows, the two extra arguments would have non-negligible costs.
|
||||
|
||||
Removing any special cases and making all calls use the ``tp_call`` form was also considered.
|
||||
However, unless a much more efficient way was found to create and destroy tuples, and to a lesser extent dictionaries,
|
||||
|
|
|
@ -27,7 +27,7 @@ Motivation
|
|||
|
||||
Whenever a project detects that a particular release on PyPI might be
|
||||
broken, they often times will want to prevent further users from
|
||||
inadvertantly using that version. However, the obvious solution of
|
||||
inadvertently using that version. However, the obvious solution of
|
||||
deleting the existing file from a repository will break users who have
|
||||
followed best practices and pinned to a specific version of the project.
|
||||
|
||||
|
@ -86,7 +86,7 @@ yanked again).
|
|||
Installers
|
||||
----------
|
||||
|
||||
The desireable experience for users is that once a file is yanked, when
|
||||
The desirable experience for users is that once a file is yanked, when
|
||||
a human being is currently trying to directly install a yanked file, that
|
||||
it fails as if that file had been deleted. However, when a human did that
|
||||
awhile ago, and now a computer is just continuing to mechanically follow
|
||||
|
|
|
@ -362,7 +362,7 @@ need to be addressed regardless of the approach used:
|
|||
|
||||
Since Roundup converts references to links when messages are
|
||||
requested, it is possible to update the target and generate the
|
||||
correct link. This need already arised several times, for
|
||||
correct link. This need already arose several times, for
|
||||
example: files and HG changesets moved from `hg.python.org` to
|
||||
GitHub and the devguide moved from `docs.python.org/devguide` to
|
||||
`devguide.python.org`.
|
||||
|
|
|
@ -125,7 +125,7 @@ Changes in stdlibs
|
|||
|
||||
But ``stdin``, ``stdout``, and ``stderr`` continue to respect
|
||||
locale encoding as well. ``PYTHONIOENCODING`` can be used to
|
||||
override thier encoding.
|
||||
override their encoding.
|
||||
|
||||
Pipes and TTY should use the "locale" encoding. UTF-8 mode [1]_
|
||||
can be used to override these encoding:
|
||||
|
@ -205,7 +205,7 @@ to UTF-8.
|
|||
But we should have deprecation period long enough. Between the
|
||||
deprecation period, users can not change the default text encoding.
|
||||
|
||||
And there are many difficulity there:
|
||||
And there are many difficulty there:
|
||||
|
||||
* Omitting ``encoding`` option is very common.
|
||||
|
||||
|
|
|
@ -240,7 +240,7 @@ To be removed:
|
|||
[#operator-module]_ [#remove-operator-funcs]_ [done]
|
||||
* ``operator.sequenceIncludes`` : redundant thanks to
|
||||
``operator.contains`` [#operator-module]_ [#remove-operator-funcs]_ [done]
|
||||
* In the thread module, the aquire_lock() and release_lock() aliases
|
||||
* In the thread module, the acquire_lock() and release_lock() aliases
|
||||
for the acquire() and release() methods on lock objects.
|
||||
(Probably also just remove the thread module as a public API,
|
||||
in favor of always using threading.py.)
|
||||
|
|
|
@ -162,7 +162,7 @@ The third argument indicates what kind of buffer the consumer is
|
|||
prepared to deal with and therefore what kind of buffer the exporter
|
||||
is allowed to return. The new buffer interface allows for much more
|
||||
complicated memory sharing possibilities. Some consumers may not be
|
||||
able to handle all the complexibity but may want to see if the
|
||||
able to handle all the complexity but may want to see if the
|
||||
exporter will let them take a simpler view to its memory.
|
||||
|
||||
In addition, some exporters may not be able to share memory in every
|
||||
|
|
|
@ -77,7 +77,7 @@ more standard Python idioms, such ``+`` or ``"".join``.
|
|||
Problem
|
||||
-------
|
||||
|
||||
Implicit String concatentation leads to tuples and lists which are
|
||||
Implicit String concatenation leads to tuples and lists which are
|
||||
shorter than they appear; this is turn can lead to confusing, or even
|
||||
silent, errors. For example, given a function which accepts several
|
||||
parameters, but offers a default value for some of them::
|
||||
|
@ -195,7 +195,7 @@ as opposed to::
|
|||
# modulus. This will no longer be available.
|
||||
"abc %s" "def" % var
|
||||
|
||||
# So the 2-to-3 translator can automically replace it with the
|
||||
# So the 2-to-3 translator can automatically replace it with the
|
||||
# (already valid):
|
||||
("abc %s" + "def") % var
|
||||
|
||||
|
|
|
@ -88,7 +88,7 @@ is not of the form ID_Start ID_Continue* anymore.
|
|||
|
||||
``ID_Continue`` is defined as all characters in ``ID_Start``, plus
|
||||
nonspacing marks (Mn), spacing combining marks (Mc), decimal number
|
||||
(Nd), connector punctuations (Pc), and characters carryig the
|
||||
(Nd), connector punctuations (Pc), and characters carrying the
|
||||
Other_ID_Continue property. Again, ``XID_Continue`` closes this set
|
||||
under NFKC-normalization; it also adds U+00B7 to support Catalan.
|
||||
|
||||
|
|
|
@ -297,7 +297,7 @@ framework). The default event loop policy is an instance of the class
|
|||
``DefaultEventLoopPolicy``. The current event loop policy object can
|
||||
be retrieved by calling ``get_event_loop_policy()``.
|
||||
|
||||
TBD: decribe child watchers and UNIX quirks for subprocess processing.
|
||||
TBD: describe child watchers and UNIX quirks for subprocess processing.
|
||||
|
||||
Passing an Event Loop Around Explicitly
|
||||
'''''''''''''''''''''''''''''''''''''''
|
||||
|
|
|
@ -664,7 +664,7 @@ Astropy
|
|||
Key people and their functions
|
||||
------------------------------
|
||||
|
||||
The Astropy Project team's responsibilites are spread over many different
|
||||
The Astropy Project team's responsibilities are spread over many different
|
||||
roles [#astropy-team]_, though frequently a person will have several roles.
|
||||
|
||||
The main body overseeing the Astropy Project is the Astropy
|
||||
|
@ -772,7 +772,7 @@ leery of fully-democratic governance models.
|
|||
References
|
||||
----------
|
||||
|
||||
.. [#astropy-team] Astropy roles and responsibilites
|
||||
.. [#astropy-team] Astropy roles and responsibilities
|
||||
https://www.astropy.org/team.html
|
||||
|
||||
.. [#astropy-apes] Astropy Proposals for Enhancement
|
||||
|
|
|
@ -290,7 +290,7 @@ Scenario if one member of the trio needs to quit
|
|||
Effective governance models provide off-ramps or temporary breaks for leaders
|
||||
who need to step down or pause their leadership service.
|
||||
|
||||
What if one member of the chosen trio has to quit, for unforseen reasons?
|
||||
What if one member of the chosen trio has to quit, for unforeseen reasons?
|
||||
|
||||
There are several possible options:
|
||||
|
||||
|
|
|
@ -154,7 +154,7 @@ the state where more support has to be demonstrated.
|
|||
Council of Elders
|
||||
=================
|
||||
|
||||
The intention of the Councel of Elders is that they, together, are capable
|
||||
The intention of the Council of Elders is that they, together, are capable
|
||||
of judging whether the will of the Python community is upheld in a specific
|
||||
vote.
|
||||
|
||||
|
@ -220,7 +220,7 @@ council as a whole, not as decisions of the individual members. In a first imple
|
|||
Elders should post under their own name (with the fact that they speak as a
|
||||
council member conferred by the topic they post to, or possibly a special badge).
|
||||
If it turns out that Elders become individual targets for ad-hominem attacks
|
||||
we should revisit this and come up with some method of anonimity.
|
||||
we should revisit this and come up with some method of anonymity.
|
||||
|
||||
.. _Ex Cathedra: https://en.wikipedia.org/wiki/Papal_infallibility
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ vote.
|
|||
|
||||
The nomination period is: January 7, 2019 through January 20, 2019
|
||||
|
||||
The voting period is: January 21, 2019 12:00 UTC through Febuary 4, 2019 12:00
|
||||
The voting period is: January 21, 2019 12:00 UTC through February 4, 2019 12:00
|
||||
UTC (The end of February 3, 2019 `Anywhere on Earth
|
||||
<http://www.ieee802.org/16/aoe.html>`_)
|
||||
|
||||
|
@ -115,7 +115,7 @@ This will create an election in which:
|
|||
* Voting is not open to the public, only those on the `Voter Roll`_ may
|
||||
participate. Ballots will be emailed when voting starts.
|
||||
* Candidates are presented in random order, to help avoid bias.
|
||||
* Voter identities and ballots are protected against cryptorgraphic advances.
|
||||
* Voter identities and ballots are protected against cryptographic advances.
|
||||
|
||||
Questions
|
||||
---------
|
||||
|
|
Loading…
Reference in New Issue