On Tue, Feb 21, 2006 at 08:02:08AM -0500, Jeremy Hylton wrote: > The lack of support for rebinding names in enclosing scopes is > certainly a wart. I think option one is a better fit for Python, > because it more closely matches the existing naming semantics. Namely > that assignment in a block creates a new name unless a global > statement indicates otherwise. The revised rules would be that > assignment creates a new name unless a global or XXX statement > indicates otherwise.
I agree with Jeremy on this. I've been thinking about doing something like this myself, but never got 'round to it. It doesn't make working with closures much easier, and I doubt it'll encourage using closures much, but it does remove the wart of needing to use mutable objects to make them read-write. > The names of naming statements are quite hard to get right, I fear. I > don't particularly like "use." It's too generic. (I don't > particularly like "scope" for option 2, either, for similar reasons. > It doesn't indicate what kind of scope issue is being declared.) The > most specifc thing I can think of is "free" to indicate that the > variable is free in the current scope. It may be too specialized a > term to be familiar to most people. I was contemplating 'enclosed' as a declaration, myself. Maybe, if there's enough of a consent on any name before Python 2.5a1 is released, and the feature isn't going to make it into 2.5, we could ease the introduction of a new keyword by issuing warning about the keyword in 2.5 already. (Rather than a future-import to enable it in 2.6.) Maybe, and only if there's no doubt about how it's going in, of course. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
