Well, now I have to delurk. I've been watching with growing excitement. Between the changes to the scope rules for list comprehensions, and this change for except blocks, I wondered if Python might have been moving in the direction of block scoped variables where appropriate as a philosophy.
I almost posted about this yesterday, but didn't. I thought that the fact these two changes had to do with scope was pure coincidence. (After all, one change is meant to add a symmetry to the language, and one is meant to fix potential gc problems.) But, on 1/10/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > BTW perhaps we should add the same semantics and syntax to 'with expr > as var'? I can't think of a reasonable use case for keeping var alive > after the with-statement terminates either. (Nor for using anything > more complex than a local variable, BTW.) +1, though I'm probably +1 for the wrong reasons. :) If it is desirable for Python to delete local variables in the face of certain syntactic constructs, then there simply does not exist a more appropriate time to do so than 'with x as y'. (Before your post, I thought the motivation of this proposal was "we'd rather not delete this variable at all, but the user will create cycles if we don't, so it's a necessary evil.") I'm coming from a philosophy, though, that believes any time a syntactic construct creates a local binding and a new suite to use it in, the binding shouldn't escape that suite. Yes, I'm really talking about 'for', and I know this is probably a controversial view. But don't the same arguments apply? (It's probably an error to use the variable outside the suite, and if you really need to, you could be explicit and store another reference to it in a separate local.) I'd also like to add that this "foo=none; del foo" approach to fake block-scopes is clever, but probably deserves a bit of extra error checking as well. Specifically, Python should generate a SyntaxWarning whenever one of these block-scope constructs binds to a local that was previously assigned to. I'm worried about this mistake going unnoticed: re = get_resource() ... try: something() except RareException as re: ... # handle it ... re.use_resource() Which *appears* to work fine most of the time, but when the RareException is raised and handled, suddenly the use_resource() line generates a surprising UnboundLocalError. These are the sort of things that should be caught ahead of time if possible. Greg F _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
