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

[Neil Toronto]

Guido van Rossum wrote:
> The semantics of __builtins__ are an implementation detail used for
> sandboxing, and assignment to __builtins__ is not supported. Alas, I
> can't quite figure out what you're after; your post doesn't start with
> a clear problem statement, so I'm not even sure if this is helpful
> information. I just hope to encourage you from trying to change the
> semantics of __builtins__. In 3.0, __builtins__ may well be renamed.

Sorry - it was very early in the morning when I did my analysis, so I 
wasn't as clear as I could have been. I had two points:

1. A suggestion for future builtins, which is probably the wrong thing 
to do. Please disregard this.

2. 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.)

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.

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)

"Immediate" semantics (which I find most correct) 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?

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

Neil