At 01:56 AM 4/20/04 +1000, Tim Delaney wrote:
Phillip J. Eby wrote:
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.
It's already backwards-incompatible. Currently, you can change the behavior of a module by modifying its attributes. A module that uses this binding approach is immune to changes in its globals. This is a *seriously* backward incompatible change, as it essentially disallows monkeypatching.
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.
Yes, I gather IronPython uses this technique as one of three alternative approaches to module globals.
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?
No. I meant that if your module above were named 'foo', then setting 'foo.x' would be disallowed.