On Wed, Jul 21, 2010 at 12:56 PM, Chris Rebert email@example.com wrote:
On Tue, Jul 20, 2010 at 3:13 PM, Nick Coghlan firstname.lastname@example.org wrote:
On Wed, Jul 21, 2010 at 6:13 AM, Alex Light email@example.com wrote:
i would use as because this whole where clause acts very similarly to a context manager in that it sets a variable to a value for a small block
No, the idea is for the indented suite to be a perfectly normal suite of Python code. We want to be able to define functions, classes, etc in there. Inventing a new mini-language specifically for these clauses would be a bad idea (and make them unnecessarily hard to understand)
<snip> Did you not read Nick's reply yet when you wrote this, or...?
Alex actually has a reasonable point here: break, continue, yield and return actually don't make sense in the top-level of the given clause (since it is conceptually all one statement).
For break and continue, they will naturally give a SyntaxError with the proposed implementation (for "'break' outside loop" or "'continue' not properly in loop", just to be randomly inconsistent).
yield and return (at the level of the given clause itself) will need to be disallowed explicitly by the compiler (similar to the "'return' outside function" and "'yield' outside function" errors you get if you attempt to use these keywords in a class or module scope).
There are also some subtleties as to whether the given clause is compiled as a closure or not (my current thoughts are that it should be compiled as a closure when defined in a function scope, but like a class scope when defined in a class or module scope).