[Python-ideas] Where-statement (Proposal for function expressions)

Mike Meyer mwm-keyword-python.b4bdba at mired.org
Fri Jul 17 00:51:12 CEST 2009


[ Maybe a little late, but nobody else seems to have noticed this...]

On Thu, 16 Jul 2009 10:51:54 -0400
Chris Perkins <chrisperkins99 at gmail.com> wrote:
> As a first approximation, assume that this code:

This seems reasonable, but there are a couple of questions. Key words:
"first approximation".

> [LHS OP] EXPR where:
>     BODY
> 
> is expanded into the equivalent of this:
> 
> def TEMP():
>     BODY
>     return EXPR
> [LHS OP] TEMP()
> 
> Problem 1) return
> Since there will be an implicit return injected into the body of TEMP,
> what happens if the user puts an explicit return in the body of the
> block:
>     x = foo(y) where:
>         return 23
> expands to
>     def TEMP():
>         return 23
>         return foo(y)
>     x = TEMP()
> So return should be disallowed.
. [ ...]
> Problem 3) yield
>     x = foo(y) where:
>         yield 3
> expands to:
>     def TEMP():
>         yield 3
>         return foo(y)
>     x = TEMP()
> which is an error. So yield must be disallowed.

I disagree with both these conclusions. Clearly, they are paired, as
they serve a similar purpose, but I don't see that they need to be
disallowed at all. That they cause problems with your first attempt at
describing an implementation certainly isn't reason to disallow them
all by itself.

On the other hand, using a where block to create some temporary names
doesn't in any way prevent me from discovering in the middle of
calculating their values that I have a value to return (or yield) from
the enclosing function. This would pretty clearly be a wart should it
be so.

That said - if where can't be implemented in such a way as to allow a
return or yield from inside a where, I don't believe that's sufficient
reason to reject where out of hand. But we shouldn't start by assuming
we have to break it.

   <mike

-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org



More information about the Python-ideas mailing list