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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4