On 20 July 2015 at 17:15, Stephen J. Turnbull <step...@xemacs.org> wrote: > ISTM that the missing rationale is that the real special case is mock > itself. Michael referred to this context, but didn't make it > explicit. Mock effectively "monkeypatches the world". In that > context, the decision to protect against certain errors whose risk is > greatly increased by mock itself arguably is a *minor* design > decision, and none of the defenders of leaving this feature in 3.5 > would consider it a precedent for admitting similar "special cases" > elsewhere in the stdlib.
Yes, Mock (especially AutoMock) is *already* quite magical from the perspective of most Pythonistas, as it relies heavily on Python's runtime introspection features to emulate other objects based on live introspection of the relevant type objects. It is however a very *practical* piece of code, as it lets you readily mock out a remote service for testing purposes, while later using those same tests against a *real* instance of the target class as functional integration tests, even if you couldn't write such API emulation code yourself. The need for the "typo detection" is then a consequence of two different kinds of methods existing in the same namespace (those from Mock itself, and those from the object being emulated), leading to a particular category of bug in normal usage of this API. Robert Collins suggested a possible migration path to better structural separation of the two kinds of Mock method, but the existing merged API is one a lot of folks actually like. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
