Q: Python 2.0 preliminary features?
skaller
skaller at maxtal.com.au
Sun Oct 17 09:02:18 EDT 1999
Guido van Rossum wrote:
>
> Regarding the use of 'global' in combination with nested scopes:
> I have always been in favor or *not* providing a way to assign to
> variables at the intermediate levels. That is, you can *use*
> variables from intermediate levels, but you can't *set* them. The
> 'global' statement will set the variable at the module-global level.
Actually, I'd be in favour of getting rid of 'global'
altogether now. It is no longer necessary, now python
has classes ...
> Motivation: I agree that it is useful to reference variables in the
> surrounding scope. But if you start modifying them, you're abusing
> the nested scope mechanism to hold mutable state; it's much clearer
> to define a class for this purpose.
>
> In particular, I think that allowing
>
> def f():
> sum = 0
> def accumulate(x):
> global sum
> sum = sum+x
> ...code using accumulate()...
> return sum
>
> tends to create obfuscated code.
I would not dispute this. I think the
problem when doing this to a module, however,
is WORSE because function stack frames are
transient, whereas a module lives forever.
The resolution to the module level
has another problem in Viper: there is no single module level.
In particular, a normal module is NOT the bottom level,
the bottom level is actually 'builtins'. Module
environments get chained together like function
stack frames, so the lookup works. [There is a possibl
extension to nested modules, which I have resisted
play with yet :-]
The problem is that there is no way to detect,
in a chain of linked environments, which one is the 'module'
level: they're ALL represented by a common abstraction.
[Of course, each environment knows it
has a particular type, and so 'function environments'
know to check for the list of globals when doing
an assignment: they just delegate to the parent
environment .. which is why my implementation
requires multiple global statements if you want to
actually reach module level from a deeply nested
function definition]
--
John Skaller, mailto:skaller at maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller
More information about the Python-list
mailing list