> Cool. Any chance of getting your keynote slides on the net? Yes, after the conference. > > > From past rumblings, I gather that Python is moving > > > towards preventing __builtins__ from being shadowed. > > > > You must be misunderstanding. > > > > The only thing I want to forbid is to stick a name in *another* > > module's globals that would shadow a builtin. > > Yes, that *is* different. > Allowing shadows means having to watch out for trees. Being poetic? > > The idea of forbidding module B in the first example is that the > > optimizer is allowed to replace len(a) with a bytecode that calls > > PyOject_Size() rather than looking up "len" in globals and builtins. > > The optimizer should only be allowed to make this assumption if > > careful analysis of an entire module doesn't reveal any possibility > > that "len" can be shadowed > . . . > > BTW this idea is quite old; I've described it a few years ago under a > > subject something like "low-hanging fruit". > > The fruit is a bit high. Doing a full module analysis means > deferring the optimization for a second pass after all the code > has already been generated. It's doable, but much harder. You're stuck in a one-pass compiler mindset. We build a parse tree for the entire module before we start generating bytecode. We already have tools to do namespace analysis for the entire tree (Jeremy added these to implement nested scopes). > def f(x): > return len(x) + 10 # knowing whether to optimize this > > def g(): > global len # when this is allowed > len = lambda x: 5 # is a bear > > The task is much simpler if it can be known in advance that > the substitution is allowed (i.e. a module level switch like: > __fastbuiltins__ = True). -1000. --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