<div dir="ltr"><div class="gmail_extra">PEP 520 review notes.<br><br></div><div class="gmail_extra">(From previous message; edited.)<br><br>- I agree it's better to define the order as computed at 
runtime.<br><br>- 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).<br><div><div><div><br></div>- 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__?)<br><br></div>- 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).<br><br></div>- 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.<br><br></div><div class="gmail_extra">(New)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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?)<br><br></div><div class="gmail_extra">- 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.<br><br></div><div class="gmail_extra">- 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.<br><br></div><div class="gmail_extra">Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more contemplation.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>