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

Nick Coghlan ncoghlan at gmail.com
Mon May 25 00:52:57 CEST 2015


On 25 May 2015 07:26, "Guido van Rossum" <guido at python.org> wrote:
>
> On Sun, May 24, 2015 at 1:36 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:

>>
>> 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.

It occurs to me that even the basic change makes it possible to provide
initialisation helpers that accept locals() from a currently running class
definition and return a definition ordered list of fields (perhaps
restricted to values of a certain type, such as database column
definitions, or webform field definitions).

>> 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".

Right, it isn't that I think __definition_order__ is necessarily a bad
idea, I just suspect it's redundant if we end up going ahead with
__init_subclass__ (which would allow a base class to opt in to preserving
the definition order, either of all fields or selected ones), and the
latter change is definitely out of scope for 3.5 at this point.

There are also other open questions, like whether or not dir() should
respect the order when reporting attribute names, or if dict_proxy should
respect the order when iterating.

Regards,
Nick.

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


More information about the Python-Dev mailing list