[Python-Dev] Preserving the definition order of class namespaces.

[Guido van Rossum]

On Sun, May 24, 2015 at 1:36 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:


> On May 24, 2015 3:35 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> > Is it specifically necessary to save the order by default? Metaclasses
> > would be able to access the ordered namespace in their __new__ method
> > regardless, and for 3.6, I still like the __init_subclass__ hook idea
> > proposed in PEP 487, which includes passing the original namespace to
> > the new hook.
> >
> > So while I'm sold on the value of making class execution namespaces
> > ordered by default, I'm not yet sold on the idea of *remembering* that
> > order without opting in to doing so in the metaclass.
> >
> > If we leave __definition_order__ out for the time being then, for the
> > vast majority of code, the fact that the ephemeral namespace used to
> > evaluate the class body switched from being a basic dictionary to an
> > ordered one would be a hidden implementation detail, rather than
> > making all type objects a little bigger.
>
> It's too late for 3.5 to negotiate much so I'll try to make my case here
> for __definition_order__ one last time.   If that's not sufficient then
> I'll defer further discussion to 3.6.
>
> My premise for storing the definition order on the class is that Guido was
> okay with using OrderedDict for cls.__dict__, which is a bigger change.
> Regardless, there are two reasons why it makes sense:
>
> * If it makes sense to use OrderedDict by default for class definition
> then it makes sense to preserve the extra information OrderedDict provides.
> * As I noted at the beginning of the thread, you could still preserve that
> info manually, but that makes it less convenient for library authors.
>
> If you still think that's not enough justification then we can table
> __definition_order__ for now.
>

Let's table it. It's hard to compare alternatives on a single dimension of
"which is a bigger change".

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