[Python-ideas] 'where' statement in Python?

[geremy condra]

On Wed, Jul 21, 2010 at 9:21 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 7/21/2010 7:24 AM, Nick Coghlan wrote:
>>
>> On Wed, Jul 21, 2010 at 9:16 PM, Stefan Behnel<stefan_ml at behnel.de>
>>  wrote:
>>>
>>> Terry Reedy, 20.07.2010 21:49:
>>>>
>>>> I did not comment then because I thought the idea of cluttering python
>>>> with augmented local namespace blocks, with no functional gain, was
>>>> rejected and dead, and hence unnecessary of comment.
>>>> -10
>>>> For me, the idea would come close to destroying (what remains of) the
>>>> simplicity that makes Python relatively easy to learn. It seems to be
>>>> associated with the (to me, cracked) idea that names are pollution.
>>>
>>> Actually, it's about *giving* names to subexpressions, that's quite the
>>> opposite.
>>
>> I think Terry's point was that you can already give names to
>> subexpressions by assigning them to variables in the current scope,
>> but some people object to that approach due to "namespace pollution".
>
> Right.
>
>> I agree with him that avoiding namespace pollution isn't a particular
>> strong argument though (unless you have really long scripts and
>
> Okay, we can leave that issue aside.
>
>> functions), which is why I've tried to emphasize the intended
>> readability benefits.
>
> whereas I am trying to emphasize the reading horror for people whose brains
> are wired differently from yours. The backwards conditional expressions are
> nearly impossible for me to read, which is to say, painful. To some,
> something like

Ok, so, your brain is wired differently. That's fine- but mine says that there
are cases where the up-front syntax is more readable. I particularly like
that it clearly marks what variables will not be used elsewhere without
forcing me to jump around in the code to find out how they're being computed.

> e = fe(a,b,c, p1) where:
>  c = fc(a, d, p2 where:
>    d = fd(a, p1) where:
>      a = fa(p1, p2)
>  b = fb(a,p2)
>
> where p1,p2 are input parameters;
>
> looks about as bad (and it was a real effort to write). I would rather
> something like that were in a branch dialect, Ypthon with its own extension
> (.yp).

Of course it looks bad. You can make anything look bad. 37 levels of nested
'for' statements look bad. That isn't an argument against this, it's an argument
against bad code period.

> Algorithm book authors usually want their books read by lots of people. When
> they invent a pseudocode language, they usually invent something lots of
> people can read. (Knuth's MIX was something of an exception.) It is often so
> close to (a subset of) Python that it is ridiculous that they do not just
> use (a subset) Python so it is not 'pseudo'. I cannot remember seeing
> anything like the above. I believe the reason is because it would be, on
> average, less readable and harder to understand.

I would use this, and would welcome it in a textbook. Telling people what you're
doing before you do it motivates the material and helps people to learn and
understand with minimal effort IMO/E.

Geremy Condra