[Python-Dev] PEP 329: Treating Builtins as Constants inthe Standard Library (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Apr 19 12:27:20 EDT 2004

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 'MAKEFUNCTION' 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.

More information about the Python-Dev mailing list