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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4