Update PEP 520 per python-dev feedback.
This commit is contained in:
parent
69c76773ee
commit
3584f0caf8
41
pep-0520.txt
41
pep-0520.txt
|
@ -78,6 +78,7 @@ The following code demonstrates roughly equivalent semantics for the
|
|||
default behavior::
|
||||
|
||||
class Meta(type):
|
||||
@classmethod
|
||||
def __prepare__(cls, *args, **kwargs):
|
||||
return OrderedDict()
|
||||
|
||||
|
@ -96,7 +97,7 @@ Why a tuple?
|
|||
|
||||
Use of a tuple reflects the fact that we are exposing the order in
|
||||
which attributes on the class were *defined*. Since the definition
|
||||
is already complete by the time ``definition_order__`` is set, the
|
||||
is already complete by the time ``__definition_order__`` is set, the
|
||||
content and order of the value won't be changing. Thus we use a type
|
||||
that communicates that state of immutability.
|
||||
|
||||
|
@ -156,6 +157,11 @@ so that consumers of ``__definition_order__`` may have a consistent
|
|||
expectation for the value. That helps maximize the feature's
|
||||
usefulness.
|
||||
|
||||
We could also also allow an arbitrary iterable for a manually set
|
||||
``__definition_order__`` and convert it into a tuple. However, not
|
||||
all iterables infer a definition order (e.g. ``set``). So we opt in
|
||||
favor of requiring a tuple.
|
||||
|
||||
Why is __definition_order__ even necessary?
|
||||
-------------------------------------------
|
||||
|
||||
|
@ -172,7 +178,8 @@ Compatibility
|
|||
|
||||
This PEP does not break backward compatibility, except in the case that
|
||||
someone relies *strictly* on ``dict`` as the class definition namespace.
|
||||
This shouldn't be a problem.
|
||||
This shouldn't be a problem since ``issubclass(OrderedDict, dict)`` is
|
||||
true.
|
||||
|
||||
|
||||
Changes
|
||||
|
@ -203,7 +210,7 @@ The implementation is found in the tracker. [impl_]
|
|||
Alternatives
|
||||
============
|
||||
|
||||
<class>.__dict__ as OrderedDict
|
||||
cls.__dict__ as OrderedDict
|
||||
-------------------------------
|
||||
|
||||
Instead of storing the definition order in ``__definition_order__``,
|
||||
|
@ -223,6 +230,34 @@ PEP 422 introduced a new "namespace" keyword arg to class definitions
|
|||
that effectively replaces the need to ``__prepare__()``. [pep422_]
|
||||
However, the proposal was withdrawn in favor of the simpler PEP 487.
|
||||
|
||||
A stdlib Metaclass that Implements __prepare__() with OrderedDict
|
||||
-----------------------------------------------------------------
|
||||
|
||||
This has all the same problems as writing your own metaclass. The
|
||||
only advantage is that you don't have to actually write this
|
||||
metaclass. So it doesn't offer any benefit in the context of this
|
||||
PEP.
|
||||
|
||||
Set __definition_order__ at Compile-time
|
||||
----------------------------------------
|
||||
|
||||
Each class's ``__qualname__`` is determined at compile-time.
|
||||
This same concept could be applied to ``__definition_order__``.
|
||||
The result of composing ``__definition_order__`` at compile-time
|
||||
would be nearly the same as doing so at run-time.
|
||||
|
||||
Comparative implementation difficulty aside, the key difference
|
||||
would be that at compile-time it would not be practical to
|
||||
preserve definition order for attributes that are set dynamically
|
||||
in the class body (e.g. ``locals()[name] = value``). However,
|
||||
they should still be reflected in the definition order. One
|
||||
posible resolution would be to require class authors to manually
|
||||
set ``__definition_order__`` if they define any class attributes
|
||||
dynamically.
|
||||
|
||||
Ultimately, the use of ``OrderedDict`` at run-time or compile-time
|
||||
discovery is almost entirely an implementation detail.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
|
Loading…
Reference in New Issue