You are right and actually I sometimes did the same thing in a temporary script such as in ipython. Because in my opinion, it's not really elegant code as one may be puzzled for the list `[f(x)]`. Well, although that's quite subjective.
And also I test the code and find another `for` clause can make time cost about 1.5 times in my computer, even when I optimize `[f(x)]` to a generator `(f(x), )`. Though that's not very big issue if you don't care about efficiency that much. But a temporary list or generator is redundant here. `[f(x)]` can be an alternative, but I think it is worth a new syntax. At 2018-02-15 18:11:47, "Stephan Houben" <stephan...@gmail.com> wrote: Note that you can already do: [y + g(y) for x in range(10) for y in [f(x)]] i.e. for y in [expr] does exactly what the OP wants. No new syntax needed. If you hang out on python-list , you'll soon notice that many newbies struggle already with the list comprehension syntax. It's a mini-language which is almost, but not entirely, exactly unlike normal Python code. Let's not complicate it further. Stephan 2018-02-15 10:53 GMT+01:00 Evpok Padding <evpok.padd...@gmail.com>: For simple cases such as `[y + g(y) for y in [f(x) for x in range(10)]]`, I don't really see what the issue is, if you really want to make it shorter, you can ``[y + g(y) for y in map(f,range(10))]` which is one of the rare case where I like `map` more than comprehensions. For more complex case, just define a intermediate generator along the lines ``` f_samples = (f(x) for x in range(10)) [y+g(y) for y in f_samples] ``` Which does exactly the same thing but - Is more readable and explicit - Has no memory overhead thanks to lazy evaluation (btw, you should consider generators for your nested comprenshions) While I am sometimes in the same state of mind, wishing for variables in comprehensions seems to me like a good indicator that your code needs refactoring. Best, E On 15 February 2018 at 10:32, Jamie Willis <jw14896.2...@my.bristol.ac.uk> wrote: > > 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: > > [expr_using_x_and_y > for i in is > x = expr_using_i > for j in is > y = expr_using_j_and_x] > > This demonstrates the scope of each assignment; available in main result and > then every clause that follows it. > > Sorry to op who will receive twice, forgot reply to all > > On 15 Feb 2018 7:03 am, "fhsxfhsx" <fhsxf...@126.com> wrote: >> >> As far as I can see, a comprehension like >> alist = [f(x) for x in range(10)] >> is better than a for-loop >> for x in range(10): >> alist.append(f(x)) >> because the previous one shows every element of the list explicitly so that >> we don't need to handle `append` mentally. >> >> But when it comes to something like >> [f(x) + g(f(x)) for x in range(10)] >> you find you have to sacrifice some readableness if you don't want two f(x) >> which might slow down your code. >> >> Someone may argue that one can write >> [y + g(y) for y in [f(x) for x in range(10)]] >> 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. >> We can even replace every comprehension with map and filter, but that would >> face the same problems. >> >> In a word, what I'm arguing is that we need a way to assign temporary >> variables in a comprehension. >> In my opinion, code like >> [y + g(y) for x in range(10) **some syntax for `y=f(x)` here**] >> is more natural than any solution we now have. >> 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. >> >> 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. >> >> >> >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/