[Python-Dev] How far to go with user-friendliness
Nick Coghlan
ncoghlan at gmail.com
Mon Jul 20 10:04:57 CEST 2015
On 20 July 2015 at 17:15, Stephen J. Turnbull <stephen at 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list