[Python-ideas] Inline assignments using "given" clauses

[Steven D'Aprano]

On Sun, May 06, 2018 at 02:00:35AM +1000, Nick Coghlan wrote:

> 3. You can stick in an explicit "if True" if you don't need the given
> variable in the filter condition
> 
>     [(fx**2, fx**3) for x in xs if True given fx = f(x)]

o_O

I'm replying to an email which is a week old. I haven't seen 
anyone other than Tim comment on that "if True" boilerplate. Are you 
still proposing that? If not, you can ignore the following.


> And then once you've had an entire release where the filter condition was
> mandatory for the comprehension form, allowing the "if True" in "[(fx**2,
> fx**3) for x in xs given fx = f(x)]" to be implicit would be less ambiguous.

I'm sorry, perhaps I'm having another slow day, but I don't see the 
ambiguity in the first place.

And I *certainly* do not see how adding in a logically superfluorous 
"if True" would make it unambiguous.

For comparison sake, here is the PEP 572 proposal compared to yours:

    [((fx := f(x))**2, fx**3) for x in xs]

I'd read that as

    for each x in xs, let fx be f of x, return fx squared and fx cube


    [(fx**2, fx**3) for x in xs if True given fx = f(x)]

which I'd read as

    for each x in xs, if True, return fx squared and fx cube, given fx is f of x

and then wonder why on earth the test is there. Explain to me again why 
this boilerplate is necessary, please. Especially since you're already 
suggesting that in a future release it could be dropped without changing 
the meaning.



[Tim Peters]
> > In
> >
> >     if match given match = pattern.search(data):
> >
> > the annoying visual redundancy (& typing) persists.
> 
> Right, but that's specific to the case where the desired condition really
> is just "bool(target)".

That really isn't the case.

    if result.method() given result = compare(data, arg):

versus the PEP 572 syntax:

    if (result := compare(data, arg)).method():

So it certainly isn't just the bool(target) case that is redundant.



-- 
Steve