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
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"
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
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
that we don't need to handle `append` mentally. 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/