Antoine Pitrou wrote:
It is useful to distinguish between globals (i.e., module-level variables) and locals, so replacing them with scope() would not be better IMO.
You have a point about globals(), so it probably makes sense for it to stay. I still think that it wouldn't hurt to subsume locals() and the proposed nonlocals() into a single function returning some kind of view object, though. But I suppose we'd have to examine use cases before deciding that. The main use case I can think of is things like print "Your %(vehicle)s is full of %(fish)s" % locals() where I can't see a good reason for restricting the lookup to locals but not nonlocals, or even globals.
If you can prove that making locals() (or its replacement) writable doesn't complicate the interpreter core too much, then why not. Otherwise -1 :-)
It shouldn't be hard to support changing the values of *existing* names, which all that I really meant. I wouldn't expect to be able to create new local names through it. -- Greg