> The question is: why make this complicated ? > > If the programmer enables __fast_builtins__ (or similar) in the > module scope, she should be aware that tweaking the module globals > from the outside won't have the desired effect. I don't want programmers to have to add all sorts of magical incantations to their top to guide the optimizer. Today it's __fast_builtins__, tomorrow it's a promise that a class won't be poked. Poking a module from the outside is frequent enough, but poking names that shadow builtins is extremely rare. So almost all modules would need __fast_builtins__, because it would almost always help. --Guido van Rossum (home page: http://www.python.org/~guido/)
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