PEP 520: Ordered Class Definition Namespace (round 3)
I've updated the PEP to reflect feedback up to this point. The
reception has been positive. 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). All other
updates to the PEP have been clarification.
Guido, at this point I believe the PEP is ready for pronouncement. *
I've included the most recent copy of the text below. Thanks.
-eric
==============================
PEP: 520
Title: Ordered Class Definition Namespace
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow
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 3)
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() C.__slots__
C.__slots__.gi_running False dir(C) [<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__
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.
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. Thanks! -Emanuel
On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry
From: Eric Snow 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?
An arbitrary iterable does not necessarily infer a definition order. For example, dict is an iterable but the order is undefined. Also, I'd rather favor simplicity for this (most likely) uncommon corner case of manually setting __definition_order__, particularly at the start. If it proves to be a problematic restriction in the future we can loosen it.
__slots__ allows any arbitrary iterable:
Yes, but __slots__ is not order-sensitive.
is already complete by the time ``definition_order__`` is set, the
Typo: missing leading underscores in __definition_order__
I'll fix that.
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.
Perhaps add a mention that isinstance(namespace, dict) will still be true, so users don't get unnecessarily confused.
Good point.
<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.
Yes, that is better. -eric
From: Eric Snow Sent: Saturday, June 11, 2016 11:02 PM To: Émanuel Barry Cc: Python-Dev Subject: Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)
On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry
wrote: From: Eric Snow 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?
An arbitrary iterable does not necessarily infer a definition order. For example, dict is an iterable but the order is undefined. Also, I'd rather favor simplicity for this (most likely) uncommon corner case of manually setting __definition_order__, particularly at the start. If it proves to be a problematic restriction in the future we can loosen it.
Point. This can always be revised later (I'm probably overthinking this as always ;)
-eric
-Emanuel
On Sun, Jun 12, 2016 at 5:37 AM, Eric Snow
The following code demonstrates roughly equivalent semantics for the default behavior::
class Meta(type): def __prepare__(cls, *args, **kwargs):
Shouldn't this be wrapped with a classmethod decorator? +1 from me. --Berker
participants (3)
-
Berker Peksağ
-
Eric Snow
-
Émanuel Barry