On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum <gu...@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 _______________________________________________ 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
