[Python-ideas] Optional extra globals dict for function objects (original) (raw)

Jim Jewett jimjjewett at gmail.com
Tue Nov 20 20:30:06 CET 2007

On 11/17/07, Neil Toronto <ntoronto at cs.byu.edu> wrote:

I set out trying to redo the 3.0 autosuper metaclass in 2.5 without bytecode hacking and ran into a problem: a function's funcglobals isn't polymorphic. That is, the interpreter uses PyDict* calls to access it, and in one case (LOADGLOBAL), actually inlines PyDictGetItem manually.

(1) Is this just one of the "this must be a real dict, not just any mapping" limits, or is there something else I'm missing?

(2) Isn't the func_globals already (a read-only reference to) the module's dict? So is this really about changing the promise of the module type, instead of just about func_globals?

Note that weakening the module.dict promise to only meeting the dict API would make it easier to implement the various speed-up-globals suggestions. And to be honest, I think that assuming a UserDict.DictMixin wouldn't be that bad. How often is a module's dict used for anything time-critical except get (and maybe set, delete, iterate)?

If it weren't for this, I could have easily done 3.0 super without bytecode hacking, by making a custom dict that allows another dict to shadow it, and putting the new super object in the shadowing dict.

...

I propose adding a read-only attribute funcextraglobals to the function object, default NULL. In the interpreter loop, global lookups try funcextraglobals first if it's not NULL.

Would this really be a global dict though, or just a closure inserted between the func and the normal globals?

Is the real problem that you can't change which variables are in a closure (rather than fully global) after the function is compiled?

-jJ

More information about the Python-ideas mailing list