> > >>>>> "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
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