[Python-ideas] Optional extra globals dict for function objects
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 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,
> 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?
More information about the Python-ideas