[Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)
vgr255 at live.ca
Sat Jun 11 22:51:29 EDT 2016
> From: Eric Snow
> Sent: Saturday, June 11, 2016 10:37 PM
> To: Python-Dev; Guido van Rossum
> Subject: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round
> The only change to the original proposal
> has been that a manually set __definition_order__ must be a tuple of
> identifiers or None (rather that using the value as-is).
> 1. if ``__definition_order__`` is defined in the class body then it
> must be a ``tuple`` of identifiers or ``None``; any other value
> will result in ``TypeError``
Why not just any arbitrary iterable, which get converted to a tuple at
runtime? __slots__ allows any arbitrary iterable:
>>> def g():
... yield "foo"
... yield "bar"
... yield "baz"
>>> class C:
... __slots__ = g()
<generator object g at 0x0074A9F0>
[<snip>, 'bar', 'baz', 'foo']
> 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
> content and order of the value won't be changing. Thus we use a type
> that communicates that state of immutability.
Typo: missing leading underscores in __definition_order__
> 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.
Perhaps add a mention that isinstance(namespace, dict) will still be true,
so users don't get unnecessarily confused.
> <class>.__dict__ as OrderedDict
<class> looks weird to me. I tend to use `cls` (although `klass` isn't
uncommon). `C` might also not be a bad choice.
More information about the Python-Dev