Home Original page

[Python-Dev] PEP 520: Ordered Class Definition Namespace

Eric Snow ericsnowcurrently at gmail.com
Mon Jun 20 21:37:44 EDT 2016 
On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum <guido at python.org> wrote:
> I agree it's better to define the order as computed at runtime. I don't
> think there's much of a point to mandate that all builtin/extension types
> reveal their order too -- I doubt there will be many uses for that -- but I
> don't want to disallow it either. But we can allow types to define this, as
> long as it's in their documentation (so users can rely on it in those
> cases).

Agreed.

>
> As another point of review, I don't like the exception for dunder names. I
> can see that __module__, __name__ etc. are distractions, but since you're
> adding methods, you should also add methods with dunder names.

I still think that in practice the dunder names will be clutter that
folks have to ignore.  However, it's a relatively weak point given
that it's easy to ignore dunder names.  So I don't mind including
them.

>
> The overlap with PEP 487 makes me think that this feature is clearly
> desirable (I like the name you give it in PEP 520 better, and PEP 487 is too
> vague about its definition).

Agreed.

>
> Finally, it seems someone is working on making all dicts ordered. Does that
> mean this will soon be obsolete?

Nope.  Having an ordered definition namespace by default does not give
us __definition_order__ for free.  Furthermore, the compact dict under
consideration isn't strictly order-preserving (re-orders for
deletion).

-eric
More information about the Python-Dev mailing list