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

[Tim Hochberg]

Skip Montanaro wrote:
>     >> How about calling new.module() to create a new module object from the
>     >> one you want to test which has suitably munged globals?
> 
>     Peter> Interesting idea... but ...
>     ...
>     Peter> # install mock open again
>     Peter> mungedMut.open = mockOpen
> 
>     Peter> What I don't understand is the difference between the final line
>     Peter> above and what I was originally trying to do, except that this is
>     Peter> a newly created module instead of one that was imported.
> 
>     Peter> Okay, I guess I must have missed a key point and I'm way off the 
>     Peter> track here.  Please clarify.
> 
> No, it turns out I was.  I was thinking you passed a bunch of stuff (like a
> dict to use as globals()) to new.module().  I guess I was thinking of
> new.code() and new.function().  You might be able to poke elements directly
> into the module's __dict__.  Perhaps new.module can grow an optional dict
> argument to handle this sort of thing.
> 
> I suggest you post your use case to python-dev as something for people there
> to think about.  In fact, new.module() would become pretty useless if you
> weren't able to do what you can do today, so I think it will probably need a
> dict argument if the "no modifying another module's globals" restriction is
> implemented.

I think that nearly this exact use case was discussed here: 
http://mail.python.org/pipermail/python-dev/2003-March/034272.html . If 
you go forward a few messages, GVR suggests adding "from __builtins__ 
import open" to modules that you might want to fiddle with.

This made me recall that the proposal was slightly more lenient than I 
initially remembered:

some_random_module.open = my_open

would be OK if open is already shadowed in some_random_module. The 
compiler then can figure out that optimizing access to open is not going 
to work.

-tim