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/
