At 02:59 PM 4/21/04 -0500, Skip Montanaro wrote: > Jim> If you really want to track changes to builtin, it is still faster > Jim> to echo builtin changes across each module than it would be to > Jim> track every name's referrers in every module (as in PEP 266.) > >This is an interesting idea but still has a problem (which I think can be >worked around). Most python apps will rarely create module-level shadows of >builtins, however if they do you have to recognize that fact when >propagating new values out to the modules. Please note that: 1. None of this is needed in order to optimize builtins. Names that are unambiguously builtins can and should be optimized at compile time. Names that are ambiguous can use the existing semantics, and nothing further need be done. 2. Modifying builtins is a hack, that needs to be supported for backward compatibility, but can and should disappear in 3.0. 3. Having official rules for a Python compiler to decide whether a name should be considered builtin or global is much more broadly useful than having a trick to speed up CPython. Several projects could make use of this, including Pyrex, Jython, PyPy, and IronPython at the least.
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