Shadowing builtins (was Re: a pyrex-inspired for-i-from-1-to-n...)

[Peter Hansen]

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!

-Peter