Adjust PEP 468 relative to the new compact dict.
This commit is contained in:
ericsnowcurrently
GitHub
parent
fd5c057e26
commit
9cf9ffb587
50
pep-0468.txt
50
pep-0468.txt
|
|
@ -9,7 +9,7 @@ Type: Standards Track
|
|||
Content-Type: text/x-rst
|
||||
Created: 5-Apr-2014
|
||||
Python-Version: 3.5
|
||||
Post-History: 5-Apr-2014
|
||||
Post-History: 5-Apr-2014,8-Sep-2016
|
||||
Resolution:
|
||||
|
||||
|
||||
|
|
@ -18,11 +18,11 @@ Abstract
|
|||
|
||||
The \*\*kwargs syntax in a function definition indicates that the
|
||||
interpreter should collect all keyword arguments that do not correspond
|
||||
to other named parameters. However,
|
||||
Python does not preserved the order in which those collected keyword
|
||||
arguments were passed to the function. In some contexts the order
|
||||
matters. This PEP introduces a mechanism by which the passed order of
|
||||
collected keyword arguments will now be preserved.
|
||||
to other named parameters. However, Python does not preserved the
|
||||
order in which those collected keyword arguments were passed to the
|
||||
function. In some contexts the order matters. This PEP dictates that
|
||||
the collected keyword arguments be exposed in the function body as an
|
||||
ordered mapping.
|
||||
|
||||
|
||||
Motivation
|
||||
|
|
@ -148,18 +148,11 @@ As will be noted below, there are ways to work around this at the
|
|||
expense of increased complication. Ultimately the simplest approach is
|
||||
the one that makes the most sense: pack collected key word arguments
|
||||
into an OrderedDict. However, without a C implementation of OrderedDict
|
||||
there isn't much to discuss. That should change in Python 3.5.
|
||||
there isn't much to discuss. That changed in Python 3.5.
|
||||
[#c_ordereddict]_
|
||||
|
||||
In some cases the difference of performance between dict and OrderedDict
|
||||
*may* be of significance. For instance: when the collected
|
||||
kwargs has an extended lifetime outside the originating function or the
|
||||
number of collected kwargs is massive. However, the difference in
|
||||
performance (both CPU and memory) in those cases should not be
|
||||
significant. Furthermore, the performance of the C OrderedDict
|
||||
implementation is essentially identical with dict for the non-mutating
|
||||
API. A concrete representation of the difference in performance will be
|
||||
a part of this proposal before its resolution.
|
||||
Note: in Python 3.6 dict is order-preserving. This virtually eliminates
|
||||
performance concerns.
|
||||
|
||||
Other Python Implementations
|
||||
----------------------------
|
||||
|
|
@ -168,8 +161,8 @@ Another important issue to consider is that new features must be
|
|||
cognizant of the multiple Python implementations. At some point each of
|
||||
them would be expected to have implemented ordered kwargs. In this
|
||||
regard there doesn't seem to be an issue with the idea. [#ironpython]_
|
||||
Each of the major Python implementations will be consulted regarding
|
||||
this proposal before its resolution.
|
||||
In informal survey of the major Python implementations has indicated
|
||||
that this feature will not be a significant burden.
|
||||
|
||||
|
||||
Specification
|
||||
|
|
@ -177,7 +170,8 @@ Specification
|
|||
|
||||
Starting in version 3.5 Python will preserve the order of keyword
|
||||
arguments as passed to a function. To accomplish this the collected
|
||||
kwargs will now be an OrderedDict rather than a dict.
|
||||
kwargs will now be an ordered mapping. Note that this does not necessarily
|
||||
mean OrderedDict. dict in CPython 3.6 is now ordered, similar to PyPy.
|
||||
|
||||
This will apply only to functions for which the definition uses the
|
||||
\*\*kwargs syntax for collecting otherwise unspecified keyword
|
||||
|
|
@ -195,7 +189,7 @@ ordered kwargs (just like any other unmatched keyword argument).
|
|||
|
||||
Note that unpacking a mapping with undefined order, such as dict, will
|
||||
preserve its iteration order like normal. It's just that the order will
|
||||
remain undefined. The OrderedDict into which the unpacked key-value
|
||||
remain undefined. The ordered mapping into which the unpacked key-value
|
||||
pairs will then be packed will not be able to provide any alternate
|
||||
ordering. This should not be surprising.
|
||||
|
||||
|
|
@ -214,7 +208,7 @@ Signature.bind_partial()) will change from a dict to an OrderedDict.
|
|||
C-API
|
||||
-----
|
||||
|
||||
TBD
|
||||
No changes.
|
||||
|
||||
Syntax
|
||||
------
|
||||
|
|
@ -226,24 +220,14 @@ Backward-Compatibility
|
|||
|
||||
The following will change:
|
||||
|
||||
* type(kwargs)
|
||||
* iteration order of kwargs will now be consistent (except of course in
|
||||
the case described above)
|
||||
* as already noted, performance will be marginally different
|
||||
|
||||
None of these should be an issue. However, each will be carefully
|
||||
considered while this proposal is under discussion.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
TBD
|
||||
|
||||
Implementation Notes
|
||||
--------------------
|
||||
|
||||
TBD
|
||||
For CPython there's nothing to do.
|
||||
|
||||
|
||||
Alternate Approaches
|
||||
|
|
@ -303,6 +287,8 @@ Prognosis:
|
|||
|
||||
The idea is still uncertain in both viability and timeframe.
|
||||
|
||||
Note that Python 3.6 now has this dict implementation.
|
||||
|
||||
\*\*\*kwargs
|
||||
------------
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue