[Python-ideas] Temporary variables in comprehensions

[Jamie Willis]

I'm not sure it does indicate a need for refactoring, I'd argue it's quite
a common pattern, at least in functional languages from which this
construct arises.

In fact, in those languages, there are laws that govern interactions with
the comprehensions (though this comes from monads and monads perhaps don't
quite apply to pythons model). These laws define behaviour that is expected
equivalent by users;

[x for x in xs] = xs
[f(x) for x in [x]] = f(x)
[g(y) for y in [f(x) for x in xs]] = [g(y) for x in xs for y in f(x)]

Even though that last law isn't completely analogous to the given example
from the OP, the transformation he wants to be able to do does arise from
the laws. So it could be argued that not being able to flatten the
comprehension down via law 3 is unexpected behaviour and in order to
achieve this you'd need a form of assignment in the comprehension or suffer
inefficiencies.

But that's probably just my functional brain talking...

On 15 Feb 2018 9:53 am, "Evpok Padding" <evpok.padding at gmail.com> wrote:

> 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.2014 at 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" <fhsxfhsx at 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 at python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >>
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180215/af6f792a/attachment-0001.html>