On 11/17/07, Neil Toronto <ntoronto@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 func_globals isn't polymorphic. That is, the interpreter uses PyDict_* calls to access it, and in one case (LOAD_GLOBAL), actually inlines PyDict_GetItem 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 func_extra_globals to the function object, default NULL. In the interpreter loop, global lookups try func_extra_globals 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