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

Steven D'Aprano steve at pearwood.info
Sat May 12 12:26:52 EDT 2018

```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]

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)]

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
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

```