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

[Neil Girdhar]

On Sat, May 12, 2018 at 11:48 PM Steven D'Aprano <steve at pearwood.info>
wrote:

> On Sat, May 12, 2018 at 11:04:45PM -0400, Neil Girdhar wrote:
> > Another benefit of given compared with := that I just thought of is this.
> > Suppose you have a generator like
> >
> > (expression(f(x), y, z)
> >  for x in xs
> >  for y in ys(x)
> >  for z in zs(y))
> >
> > With given notation you can optimize:
> >
> > (expression(f_x, y, z)
> >  for x in xs
> >  given f_x = f(x)
> >  for y in ys(x)
> >  for z in zs(y))
> >
> > whereas with :=, you can't.
>
> Is that legal syntax? You're splitting the "given" expression by
> sticking the for clause in the middle of it. I don't think that will be
> legal. It would be trying to split an ternary if:
>
>     (true_expr for x in xs if condition else false_expr for y in ys)
>
>     (true_expr if condition for x in xs else false_expr for y in ys)
>
>
>
You're right that it's a different proposal, but I thought it would be a
natural extension to this proposal since at the start of this discussion
someone mentioned how this could be accomplished with something like

(expression
for x in xs
for f_x in [f(x)])

The regular given proposal is an extension of (I think) "expr" into
something like

expr ["given" test annassign]

I think a natural extension of that is to add it to "testlist_comp" and
"dictorsetmaker" so that

given name = value

can be used a cleaner synonym of something like

for name in [value]

 But your'e right, it's a different proposal and I'm getting ahead of
things.

But whether legal or not, Neil, you went on at length about how
> professionals don't write code like this and such overly dense
> comprehensions are only fit for competitions.
>
> Now you want your cake and to eat it too:
>
>     "given is better, because it doesn't allow the awful
>     unreadable code that := gives; oh, and it's also better,
>     because it allows *this* awful unreadable code that :=
>     doesn't allow"
>
>
> In any case, of course you can write this with := binding expression.
> You just shouldn't do it:
>
>     (expression(f_x, y, z) for x in xs
>          for y in ys(x)
>          for z in zs(y)
>          if (f_x := f(x)) or True)
>          )
>
>
> That's fine for mucking about, but I wouldn't do it for serious code.
> Replacing the colon with "given f_x" doesn't change that.
>
>
My thought is that if each component is simple enough *and* if each
component can be reasoned about independently of the others, then it's
fine.  The issue I had with the := code you presented was that it was
impossible to reason about the components independently from the whole.

Ultimately, this is one of feelings.  I think every one of us has a unique
set of experiences, and those experiences led us to having different
programming aesthetics.  I used to write code one way, and then after lots
of code reviews, my experience has made me write code a different way.

Best,

Neil

>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/CFuqwmE8s-E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180513/0ff9e58e/attachment.html>