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

[Guido van Rossum]

PEP 520 review notes.

(From previous message; edited.)

- 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. We can allow
types to define this, as long as it's in their documentation (so users can
rely on it in those cases).

- I don't like the exception for dunder names. I can see that __module__,
__name__ etc. that occur in every class are distractions, but since you're
adding methods, you should also add methods with dunder names like __init__
or __getattr__. (Otherwise, what if someone really wanted to create a
Django form with a field named __dunder__?)

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

- It seems someone is working on making all dicts ordered. Does that mean
this will soon be obsolete? It would be a shame if we ended up having to
give every class an extra attribute that is just a materialization of
C.__dict__.keys() with (some) dunder names filtered out.

(New)

- It's a shame we can't just make __dict__ (a proxy to) an OrderedDict,
then we wouldn't need an extra attribute. Hm, maybe we could customize the
proxy class so its keys(), values(), items() views return things in the
order of __definition_order__? (In the tracker discussion this was
considered a big deal, but given that a class __dict__ is already a
readonly proxy I'm not sure I agree. Or is this about C level access? How
much of that would break?)

- I don't see why it needs to be a read-only attribute. There are very few
of those -- in general we let users play around with things unless we have
a hard reason to restrict assignment (e.g. the interpreter's internal state
could be compromised). I don't see such a hard reason here.

- All in all the motivation is fairly weak -- it seems to be mostly
motivated on avoiding a custom metaclass for this purpose because combining
metaclasses is a pain. I realize it's only a small patch in a small corner
of the language, but I do worry about repercussions -- it's an API that's
going to be used for new (and useful) purposes so we will never be able to
get rid of it.

Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more
contemplation.

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