[Python-ideas] Tweaking closures and lexical scoping to include the function being defined
jeanpierreda at gmail.com
Thu Sep 29 20:25:37 CEST 2011
> I don't think supporting monkey-patching is necessary
Nothing is necessary. I maintain it is extremely useful for testing.
There are entire libraries built around monkeypatching code for the
purpose of testing it. For example, recently I saw Exocet, which
allows you to create a new module object but replacing the imports
with whatever you want.(The analogue here would be copying a function,
but with new closure variables).
Without this you can't really _unit_ test a closure, at least as I
understand it. It becomes inextricably linked with its scope, which is
not what you want to test.
On Thu, Sep 29, 2011 at 2:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Sep 29, 2011 at 1:41 PM, Devin Jeanpierre
> <jeanpierreda at gmail.com> wrote:
>>> And, as I have said several times, I agree closures currently impose
>>> testability problems, but I think the answer there lies in providing
>>> better introspection tools to lessen those problems rather than
>>> advising people not to use closures specifically for those reasons.
>> OK, that's fair.
>> In order to support testing you'd need to be able to assign to closure
>> variables (for e.g. mocking) and read them (to test alterations to
>> global state). At that point it's a short leap to defining a decorator
>> that creates these nonlocals. Is there a compelling reason to use a
>> new syntax?
> I don't think supporting monkey-patching is necessary - the code under
> test will presumably provide some mechanism to control how the hidden
> state is initialised or modified. The missing part from a testing
> point of view is the ability to get that information back out in a
> clean, portable way so you can make assertions about it for whitebox
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas