[Python-Dev] Re: Dynamic nested scopes

[Gordon McMillan]

> 
> >>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

>     GvR> Of course you still will be able to define functions whose
>     GvR> name overrides a built-in -- in that case the compiler can
>     GvR> see that you're doing that (because it knows the scope rules
>     GvR> and can see what you are doing).  But you won't be able to
>     GvR> confuse someone else's module by secretly sticking a
>     GvR> replacement built-in into their module's __dict__.

[A Craven Dog overrides builtin open...]

> Would this be illegal?  Would other modules in my application (even if
> imported from the standard library!) automatically get
> debugging_open() for open() like they do now?

I have always found it very elegant & powerful that keyword 
"import" calls builtin __import__, and that well-behaved C goes 
through the same hook. In a similar vein, I have for quite 
awhile wanted to experiment with mountable virtual file 
systems so that I can "mount" a (for example) MetaKit 
database at /cheesewhiz and other modules in my app, when 
navigating into /cheesewhiz will, unbeknownst to them, be 
reading from the MetaKit DB (these ideas leaked from tcl-land 
by Jean-Claude).

I most definitely appreciate that these facilities are dangerous 
and this type of stuff tends to be abused gratuitously (eg, 
most import hacks), but disallowing them might be considered 
a gratuitous limitation (heck - Barry knows how to bypass the 
governor on every cheezewhizzer ever manufactured).

- Gordon