[Python-ideas] __builtins__ behavior and... the FUTURE!

[Guido van Rossum]

On Nov 26, 2007 12:50 PM, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> [...] A question about which semantics fast globals should support, and how
> different they can be from the current semantics and still be acceptable.
>
> I have two problems with the current semantics:
>
> 1. They seem very wrong to me, even for an implementation detail. Python
> developers rely on function behavior being invariant to the call site.
> (As much as Python developers could be said to rely on any invariance,
> anyway.)

Please assume I didn't read your initial post. "Very wrong" is a
strong stance. Care to explain what's wrong and why? Without more info
I'm not sure I understand what you're saying about call site
invariance.

> 2. Implementing the current semantics with fast globals seems
> unnecessary. It no longer helps performance (it hurts it a tiny bit),
> and the code that does it reads like a pasted-on hack.

Please provide full context (I'm also behind on the fast globals
thread). What exactly do you mean by "the current semantics"? And
what's the problem with implementing it with fast globals?

> I've since discovered that it wouldn't be much slower. Here are some
> times for one of my "builtins get" benchmarks:
>
> Current builtins:                    3.11 sec
> Fast builtins, immediate semantics:  1.81 sec
> Fast builtins, current or pre-1998:  1.64 sec (+ epsilon for hack)

Where's the benchmark source code?

> "Immediate" semantics (which I find most correct)

Even though I already told you not to care?

> are a little slower
> because it has to check whether __builtins__ has changed every time a
> globals lookup fails, before it does a builtins lookup. In "pre-1998"
> semantics, a change of __builtins__ is checked only with a new stack frame.
>
> Besides those results, fast globals reduces function call overhead by
> 10%. I haven't measured what effect the hack has on that.
>
> Personally, I like fast globals with pre-1998 semantics best, though
> there's still a difference in meaning between script and interactive
> mode. I can do it that way, the current way, or the immediate way. Or I
> could make current vs. pre-1998 selectable by macro. Do you have a
> preference?

Given that *nobody* should assign to __builtins__ in their current
globals, *ever*, I'm fine with pre-1998 semantics if it's fastest.

> I swear, though, I'm nearly ready to post a patch. :)

Please consider posting it before replying to this post.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)