On Nov 26, 2007 12:50 PM, Neil Toronto email@example.com 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:
- 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.
- 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.