On 04/01/2011 01:02, Guido van Rossum wrote: > On Mon, Jan 3, 2011 at 9:52 AM, David Malcolm<dmalcolm at redhat.com> wrote: >> On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote: >>> On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor<alex.gaynor at gmail.com> wrote: >>>> No, it's singularly impossible to prove that any global load will be any given >>>> value at compile time. Any optimization based on this premise is wrong. >>> True. >>> >>> My proposed way out of this conundrum has been to change the language >>> semantics slightly so that global names which (a) coincide with a >>> builtin, and (b) have no explicit assignment to them in the current >>> module, would be fair game for such optimizations, with the >>> understanding that the presence of e.g. "len = len" anywhere in the >>> module (even in dead code!) would be sufficient to disable the >>> optimization. >>> >>> But barring someone interested in implementing something based on this >>> rule, the proposal has languished for many years. >> Is there a PEP for this? > Not that I know of, otherwise I'd have mentioned it. :-) > > It would be useful if someone wrote it up, since the idea comes back > in one form or another regularly. > >>> FWIW, this is reminiscent of Fortran's rules for "intrinsics" (its >>> name for builtins), which have a similar optimization behavior (except >>> there the potential overrides that the compiler doesn't need to take >>> into account are load-time definitions). >> I've been attempting another way in: >> http://bugs.python.org/issue10399 >> using a new "JUMP_IF_SPECIALIZABLE" opcode. This compares what a value >> is against a compile-time prediction, branching to an optimized >> implementation if the guess was correct. I use this to implement >> function-call inlining within the generated bytecode. > Yeah, that's what everybody proposes to keep the language semantics > unchanged. But I claim that an easier solution is to say to hell with > those semantics, let's change them to make the implementation simpler. > That's from the Zen of Python: "If the implementation is easy to > explain, it may be a good idea." I guess few people can seriously > propose to change Python's semantics, that's why *I* am proposing it. > :-) Note that the semantics of locals (e.g. UnboundLocalError) were > also changed specifically to allow a significant optimization -- again > by me. > I think someone else pointed this out, but replacing builtins externally to a module is actually common for testing. In particular replacing the open function, but also other builtins, is often done temporarily to replace it with a mock. It seems like this optimisation would break those tests. Michael >> Caveat-of-doom: That code's very much a work-in-progress at this stage, >> though: sometimes it doesn't segfault :) and the way that I track the >> predicted values is taking some other liberties with semantics (see that >> URL and the dmalcolm-ast-optimization-branch in SVN). >> >> (There's probably at least 2 PEPs in the above idea, though have yet to >> write my first PEP) > If you want to write up a PEP for the semantics change I am proposing, > everything you need is in this thread. > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
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