A generator can be a good idea, however, I wonder if it's really readable to have a `f_samples`.
And the structure is the same as in
[y + g(y) for y in [f(x) for x in range(10)]]
if you replace the list with a generator. And it's similar for other solutions you mentioned.
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.
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.
At 2018-02-15 17:53:21, "Evpok Padding"
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 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/