<div dir="ltr"><div><div><div><div><div><div><div>Note that you can already do:<br><br> [y + g(y) for x in range(10) for y in [f(x)]]<br><br></div>i.e. for y in [expr]<br></div>does exactly what the OP wants.<br></div>No new syntax needed.<br><br></div>If you hang out on python-list , you'll soon notice<br></div>that many newbies struggle already with the list comprehension<br></div>syntax. <br></div><div>It's a mini-language which is almost, but not entirely,<br></div><div>exactly unlike normal Python code.<br></div><div>Let's not complicate it further.<br></div><div><br></div><div>Stephan<br></div> <br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-15 10:53 GMT+01:00 Evpok Padding <span dir="ltr"><<a href="mailto:evpok.padding@gmail.com" target="_blank">evpok.padding@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div class="h5"><div><br></div>On 15 February 2018 at 10:32, Jamie Willis <<a href="mailto:jw14896.2014@my.bristol.ac.uk" target="_blank">jw14896.2014@my.bristol.ac.uk</a><wbr>> 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" target="_blank">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>>> ______________________________<wbr>_________________<br>>> Python-ideas mailing list<br>>> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>>> <a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>>> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>>><br>><br>> ______________________________<wbr>_________________<br>> Python-ideas mailing list<br>> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>> <a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>><br></div></div></div>
<br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div>