Shadowing builtins (was Re: a pyrex-inspired for-i-from-1-to-n...)
peter at engcorp.com
Thu Apr 3 02:16:09 CEST 2003
Skip Montanaro wrote:
> Tim> I think that nearly this exact use case was discussed here:
> Tim> http://mail.python.org/pipermail/python-dev/2003-March/034272.html
> Tim> . If you go forward a few messages, GVR suggests adding "from
> Tim> __builtins__ import open" to modules that you might want to fiddle
> Tim> with.
> Yeah, but that's quite different from Peter's use case, where he wants to
> unit test a module more-or-less from the outside. He shouldn't have to add
> hooks in the module itself to unit test it.
> Tim> This made me recall that the proposal was slightly more lenient
> Tim> than I initially remembered:
> Tim> some_random_module.open = my_open
> Tim> would be OK if open is already shadowed in some_random_module. The
> Tim> compiler then can figure out that optimizing access to open is not
> Tim> going to work.
> That won't help Peter either. I suspect all of the modules he wants to test
> don't actually shadow open().
Very true. There is definitely NO desire to have to munge the internals
of the code under test, just to let it be tested.
I hope Greg's comments about being able to disable this are on the mark,
because otherwise this would be a clear case of a desire for (unnecessary,
IMHO) optimization being given higher priority than maintaining one of
Python's strongest advantages. Speed will *never* be Python's strongest
suit, but its dynamicism clearly is; let's not bugger that up!
More information about the Python-list