Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
If there are no objections, I would like to revive this. All we need to do is add a one-line guarantee to the docs and a test to back it up. Except for the aberration on Py3.5, add_subclass() tracks new subclasses in the order created. This behavior is intuitive and potentially useful. Unless there is a compelling reason to switch the underlying container to a set object, no other reasonable implementation choice would upset the current behavior. I think the OP's request was reasonable. For us, guaranteeing the current behavior is not a difficult thing to do. If we don't, the alternative for the user isn't reasonable. They would need to write a new metaclass that does almost exactly what we already do, except that they can guarantee the use of an ordered collection. This seems silly when we already use an ordered collection but haven't made it a promise. ---------- nosy: +rhettinger resolution: wont fix -> status: closed -> open _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34805> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
