<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>A generator can be a good idea, however, I wonder if it's really readable to have a `f_samples`.<br>And the structure is the same as in<br><span style="font-family:monospace">[y + g(y) for y in [f(x) for x in range(10)]]</span></div><div>if you replace the list with a generator. And it's similar for other solutions you mentioned.<br>Well, I know that it can be quite different for everyone to determine whether a piece of code is readable or not, maybe it's wise to wait for more opinions. <br><br>There's another problem that, as you distinguished the `simple` and `more complex` case, the offered solutions seem very specific, I'm not sure if there's a universal solution for every case of temporary variables in comprehensions. If not, I think it's too high cost to reject a new syntax if you need to work out a new solution every time.<br><br></div><br><br><br><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><br>At 2018-02-15 17:53:21, "Evpok Padding" <evpok.padding@gmail.com> wrote:<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div dir="ltr">For simple cases such as `[y + g(y) for y in [f(x) for x in range(10)]]`,<br>I don't really see what the issue is, if you really want to make it shorter,<br><div>you can ``[y + g(y) for y in map(f,range(10))]` which is one of the rare</div><div>case where I like `map` more than comprehensions.</div><div><br></div><div>For more complex case, just define a intermediate generator along the lines<br></div><div>```</div><div>f_samples = (f(x) for x in range(10))</div><div>[y+g(y) for y in f_samples]</div><div>```</div><div>Which does exactly the same thing but</div><div>  - Is more readable and explicit<br></div><div>  - Has no memory overhead thanks to lazy evaluation</div><div>    (btw, you should consider generators for your nested comprenshions)</div><div><br></div><div>While I am sometimes in the same state of mind, wishing for variables in</div><div>comprehensions seems to me like a good indicator that your code needs</div><div>refactoring.</div><div><br></div><div>Best,</div><div><br></div><div>E</div><div><br></div>On 15 February 2018 at 10:32, Jamie Willis <<a href="mailto:jw14896.2014@my.bristol.ac.uk">jw14896.2014@my.bristol.ac.uk</a>> wrote:<br>><br>> I +1 this at surface level; Both Haskell list comprehensions and Scala for comprehensions have variable assignment in them, even between iterating and this is often very useful. Perhaps syntax can be generalised as:<br>><br>> [expr_using_x_and_y<br>>  for i in is<br>>   x = expr_using_i<br>>  for j in is<br>>   y = expr_using_j_and_x]<br>><br>> This demonstrates the scope of each assignment; available in main result and then every clause that follows it. <br>><br>> Sorry to op who will receive twice, forgot reply to all<br>><br>> On 15 Feb 2018 7:03 am, "fhsxfhsx" <<a href="mailto:fhsxfhsx@126.com">fhsxfhsx@126.com</a>> wrote:<br>>><br>>> As far as I can see, a comprehension like<br>>> alist = [f(x) for x in range(10)]<br>>> is better than a for-loop<br>>> for x in range(10):<br>>>   alist.append(f(x))<br>>> because the previous one shows every element of the list explicitly so that we don't need to handle `append` mentally.<br>>><br>>> But when it comes to something like<br>>> [f(x) + g(f(x)) for x in range(10)]<br>>> you find you have to sacrifice some readableness if you don't want two f(x) which might slow down your code.<br>>><br>>> Someone may argue that one can write<br>>> [y + g(y) for y in [f(x) for x in range(10)]]<br>>> but it's not as clear as to show what `y` is in a subsequent clause, not to say there'll be another temporary list built in the process.<br>>> We can even replace every comprehension with map and filter, but that would face the same problems.<br>>><br>>> In a word, what I'm arguing is that we need a way to assign temporary variables in a comprehension.<br>>> In my opinion, code like<br>>> [y + g(y) for x in range(10) **some syntax for `y=f(x)` here**]<br>>> is more natural than any solution we now have.<br>>> And that's why I pro the new syntax, it's clear, explicit and readable, and is nothing beyond the functionality of the present comprehensions so it's not complicated.<br>>><br>>> And I hope the discussion could focus more on whether we should allow assigning temporary variables in comprehensions rather than how to solve the specific example I mentioned above.<br>>><br>>><br>>>  <br>>><br>>><br>>> _______________________________________________<br>>> Python-ideas mailing list<br>>> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>>> <a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a><br>>> Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a><br>>><br>><br>> _______________________________________________<br>> Python-ideas mailing list<br>> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>> <a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a><br>> Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a><br>><br></div>
</blockquote></div><br><br><span title="neteasefooter"><p> </p></span>