[Python-Dev] PEP 329: Treating Builtins as Constants in the Standard Library

[Brett C.]

Guido van Rossum wrote:

> [Brett Cannon]
> 
>>Just to make sure I am understanding this, are you suggesting a possible 
>>statement like ``volatile len`` to flag that len may be changed?
> 
> 
> Yeah, but not that syntax.  (I'm not proposing any syntax at this point.)
> 

Right.  I just wanted to write it out in some form.  Didn't mean to 
imply that is what you were suggesting.

> 
>>That way all "volatile"-flagged globals and one that are redefined
>>in the module use LOAD_GLOBAL while all other built-ins either get
>>them set to locals or use a LOAD_BUILTIN opcode?
> 
> 
> Sort of, although I think you meant STORE_GLOBAL rather than
> LOAD_GLOBAL.  Exactly how this would be implemented is up to the
> bytecode compiler; I can see that some cheap builtins (e.g. len) may
> be turned into special opcodes so that no lookup is used at all.
> 

I actually was thinking of LOAD_GLOBAL; I was thinking of ``foo = 
len(x)`` which loads len (global), loads x (local), calls len, and then 
stores into foo (local).  That is what Raymond's code is optimizing; 
storing built-ins into the local namespace to skip having to try load 
from the global namespace, fail, and then check the built-in namespace 
(which are both slower than local since they are dictionaries and not an 
array like locals) (I just realized how much "talking out load" text I 
put in my emails; I'm a talker =).

As for the cheap opcodes, it seems reasonable for the frequently used 
built-ins.

And as for implementation, while I am thinking about it, storing 
built-ins into the local namespace would be the fastest, but using a 
LOAD_BUILTIN opcode would allow for universal overriding of built-ins if 
so desired.  That is going to be an interesting thread if this ends up 
coming to fruition.  =)

> 
>>Or am I getting the use of volatile reversed (which would make more 
>>backwards-compatible)?
> 
> 
> You're not getting it reversed.  Having to flag the ones that are not
> volatile would indeed be more backward compatible, but it would
> require everybody to put lots of 'nonvolatile' statements in all the
> time just in the hope to get faster code.  That's what I'm trying to
> avoid, and that's why I'm not psyched about Raymond's (or anybody's!) 
> proposed "make this function faster" API.  Given that "volatile"
> globals are very rare, it makes more sense to put the burden on the
> programmer who needs his seemingly-constant globals to be reloaded.
> 

Right.  I know one of the reasons I enjoy programming in Python is that 
I don't have to think about optimizations when I code.  If I want some 
non-standard use of the language I have no issue of jumping through some 
hoops (such as defining something as volatile) but the base case 
(programming for "cases 90% of the time" as Neal and Jeremy pointed out 
to me at PyCon) is simple and does not require extra thought.

> 
>>If we go with the former interpretation I take it we would still
>>need to get that warning Neil worked on a while back for warning
>>people when someone is injecting into a module's global namespace.
> 
> 
> Yeah, that warning is still the right thing to do, but it's
> implementation was a nuisance because there were some legit cases that
> it couldn't know about.  I don't recall -- did we turn it into a
> silent deprecation or did we just delete the warning?
> 

I thought we just ripped it out since it never quite worked perfectly, 
but I could be wrong.

-Brett