I had a use case where `MyClass.__subclasses__()` returning classes in the definition order would have made the code simpler. They seemed to be returned in that order, but because the docs didn't say anything about it [1] I did some searching to find out can I trust the order to stay the same also in the future.

Based on my searches it seems that prior to Python 3.5 the information was stored in a list and that preserved the order. In Python 3.5 the information was stored into a dict for performance reasons as part of issue 17936 [2]. Back then dicts weren't ordered, so the order is undefined in Python 3.5, but in Python 3.6+ the order is again preserved. In practice Python 3.5 is the only current version where the order of `__subclasses__()` is not defined.

My proposal is to make the current, and old, behavior of returning classes from `__subclassses__()` in definition order explicit. If nobody has anything against that, I'd be willing to provide a pull request updating docs and adding unit tests making sure the order is not messed up in the future. Let me also know if even this kind of simple changes would need to go through python-ideas or python-dev. The PEP process feels overkill when there are no code changes required.


PS: I know both Antoine and Guido commented issue 17936 [3] that they don't know any use cases for the order. I can explain my use case if someone is interested.

[1] https://docs.python.org/3/library/stdtypes.html?highlight=__subclasses__#class.__subclasses__
[2] https://bugs.python.org/issue17936
[3] https://bugs.python.org/issue17936#msg189959