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

Brett C. bac at OCF.Berkeley.EDU
Mon Apr 19 15:27:54 EDT 2004

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 LOADGLOBAL while all other built-ins either get them set to locals or use a LOADBUILTIN opcode? Sort of, although I think you meant STOREGLOBAL rather than LOADGLOBAL. 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

More information about the Python-Dev mailing list