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

[Neil Toronto]

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. 
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 know it's for performance, and that if func_globals were made 
polymorphic, it'd bring the pystone benchmark to its knees, begging for 
a quick and merciful death. That's not what I'm proposing.

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. It's accessed using 
PyObject_* functions.

Here are the reasons I think this is a good idea:

- It should have near zero impact on performance in the general case 
because NULL checks are quick. There would be another attribute in the 
frame object (f_extra_globals), almost always NULL.

- Language enhancement prototypes that currently use bytecode hacking 
could be accomplished with a method wrapper and a func_extra_globals 
dict. The prototypes could be pure Python, and thus more general, less 
brittle, and easier to get right. Hacking closures is nasty business.

- I'm sure lots of other stuff that I can't think of, where it'd be nice 
to dynamically add information to a method or function that can be 
accessed as a variable. Pure-Python function preambles whose results can 
be seen by the original function would be pretty sweet.

- Because func_extra_globals would be read-only and default NULL, it'd 
almost always be obvious when it's getting messed with. A 
wrapper/decorator or a metaclass, and a call to types.FunctionType() 
would signal that.

- func_globals would almost never have to be overridden: for most 
purposes (besides security), shadowing it is actually better, as it 
leaves the function's module fully accessible.

Anybody else think it's awesome? :) How about opinions of major suckage?

If it helps acceptance, I'd be willing to make a patch for this. It 
looks pretty straightforward.

Neil