>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:
GvR> The built-in names have always been part of the language
GvR> definition in my mind. The way they are implemented doesn't
GvR> reflect this, but that's just an implementation detail. How
GvR> would you like it if something claimed to be Python but
GvR> didn't support len()? Or map()?
GvR> That doesn't mean you can't add new built-ins, and I don't
GvR> think that the new implementation will prevent that -- but it
GvR> *will* assume that you don't mess with the definitions of the
GvR> existing built-ins.
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__.
I'm a little confused. I've occasionally done the following within an
application:
----------driver.py
# need to override built-in open() to do extra debugging
def debuggin_open(filename, mode, bufsize):
# ...
if EXTRA_DEBUGGING:
import __builtin__.__dict__['open'] = debugging_open
-------------------- snip snip --------------------
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?
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4