[Python-ideas] Inline assignments using "given" clauses
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)]
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
> > 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.
More information about the Python-ideas