On Sat, May 12, 2018 at 11:48 PM Steven D'Aprano <[email protected]> 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 > [email protected] > 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 > [email protected]. > For more options, visit https://groups.google.com/d/optout. >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
