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