[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

[Guido van Rossum]

On Fri, Jun 24, 2016 at 3:46 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:

> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > This version looks fine to me.
>
> \o/
>

Same to me, mostly.


> > The definition order question has been dropped from PEP 487, so this
> > cross-reference doesn't really make sense any more :)
>
> Ah, so much for my appeal to authority. <wink>
>
> > I'd characterise this section at the language definition level as the
> > default class definition namespace now being *permitted* to be an
> > OrderedDict. For implementations where dict is ordered by default,
> > there's no requirement to switch specifically to
> > collections.OrderedDict.
>
> Yeah, I'd meant to fix that.
>

Please do.


> > This paragraph is a little confusing, since "set
> > ``__definition_order__`` manually" is ambiguous.
> >
> > "supply an explicit ``__definition_order__`` via the class namespace"
> > might be clearer.
>
> ack
>
> > I realised there's another important reason for doing it this way by
> > default: it's *really easy* to write a "skip_dunder_names" filter that
> > leaves out dunder names from an arbitrary interable of strings. It's
> > flatout *impossible* to restore the dunder attribute order if the
> > class definition process throws it away.
>
> Yep.  That's why I felt fine with relaxing that.  I guess I didn't
> actually put that in the PEP though. :)
>

Please add it. I'd also like the PEP point out that there might be other
things that an app wouldn't want in the definition order, e.g. anything
that's a method, or anything that starts with '_', etc.

I still think that it should not be read-only. If __slots__ and __name__
can be writable I think __definition_order__ can be too. (I believe an easy
way to make it so should be to add it to the dict that's passed to
type.__new__().)

Other nits:

- I don't think it's great to let other implementations leave
__definition_order__ set to None when they don't care to support it; this
would break apps/libraries that want to use it and the implementation could
refuse to fix it, claiming PEP 520 doesn't mandate it. I think it's better
to mandate this from a confirming implementation.

- I don't think there's much of a use case for setting __definition_order__
(to a tuple) for builtin classes. However I do think extension modules
should be allowed to set it, in case they are substituting for a previous
Python-level class whose users expect this to work.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160626/3700fbc9/attachment.html>