Phillip J. Eby wrote:
At 08:54 AM 4/19/04 -0400, Raymond Hettinger wrote:
Comments are invited on a new pep:
I'm not sure I understand the reasoning for implementing this via a bytecode hack, rather than in the compiler or loading mechanisms. I think I'd rather see something like:
from __future__ import fast_globals
+1. The semantics would have to be that globals *may* be optimised when the above is present (and code should assume that they will be) but there is no guarantee i.e. code should work both in the presence and absence of the above. This allows Jython (for example) to ignore it entirely, partially implement it, or completely implement it as desired. An additional bonus is that this puts it up front, so someone reading the code knows that the author is expecting optimisations to occur - when it's at the end it's much more likely to be missed, and also much less likely to be taken into account when reading the code.
which would mean that globals and builtins could be considered constants unless declared with 'global' at the module level.
This would be a backwards-incompatible change (and hence definitely warranting the __future__) but I presume you mean considered constant within the module that they are defined - hence essentially a non-issue.
Then, the compiler could optimize any undeclared builtins, and the 'MAKE_FUNCTION' opcode could bind any constants defined as of the function's declaration.
I know it's been suggested before, but I believe the idea of module-level locals - an indexed lookup rather than a dict lookup - might be worthwhile considering as part of this. That would also give improved performance for external modules using module-level names.
Finally, the module object thus created would ban any __setattr__ on any constant that has been bound into a function. (Since these are the only setattrs that could cause harm.)
It's late (2am), so I'm not entirely sure I understand this - do you mean something like: class X: pass x = X() def func(): print x x.a = 1 would throw an exception? Why would this cause a problem? The above would become almost equivalent to: class X: pass x = X() def func(): global x _x = x print _x x.a = 1 and I don't see a problem with that. Tim Delaney