[Python-Dev] PEP 329: Treating Builtins as Constants inthe Standard Library

[Phillip J. Eby]

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.