On Sun, May 24, 2015 at 1:36 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote:
> On May 24, 2015 3:35 AM, "Nick Coghlan" <ncogh...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
