Raymond Hettinger added the comment: Eric, I believe you're profoundly misunderstanding my Pycon talk. The posted code is not expected "to work if I swap the order of the classes around" -- MRO's are controlled by the child classes (subject to a number of constraints) and the order classes are listed matters greatly. Also, cooperative classes have to be designed cooperatively. The standard library OD class was intentionally tightly bound to its parent class to provide opportunities for a C implementation, to provide acceptable performance, and to make it easier for Jython and PyPy to implement the OD in ways favorable to their implementations. Likewise it was intentional to hide access to the underlying dict using name mangling for the same reasons (that one was Guido's suggestion). Also note, Guido's defaultdict also won't let you step in-between the class and its parent.
Also, your posted mal-functioning wrapper is mis-implemented. Please see the "How to Incorporate a Non-cooperative Class" section of the referenced blog post. The dependency injection technique is something that be used when testing your own subclasses which were built a loose coupling to a "default supplier" and where the calls between the consumer and supplier are a well defined part of the public API. Only a handful of standard library tools were meant to be used this way. (That is why I the non-cooperative class integration part of the blog post was necessary). I've reclassified the tracker item as a feature request for 3.6. Without compelling use cases, it will likely be re-rejected shortly. That said, I'm concerned that you've got "a burr under your saddle" and won't take no for an answer, so I'll leave this open for a while to allow you a chance to think about it and re-close it yourself. I hope your will understand that we have valid reasons for not over-specifying the API and have a reluctance to tie our hands to the implementation details as the OD gets transitioned to a C implementation suitable internal use within the core. FWIW, the OD code is pure python and there's nothing stopping you from using your own variants. ---------- priority: normal -> low type: -> enhancement versions: -Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24685> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
