[Python-ideas] Optional extra globals dict for function objects

[Jim Jewett]

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,
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