The recent thread on variable assignment in comprehensions has
prompted me to finally share
https://gist.github.com/ncoghlan/a1b0482fc1ee3c3a11fc7ae64833a315 with
a wider audience (see the comments there for some notes on iterations
I've already been through on the idea).
== The general idea ==
Hello, talking about this syntax :
[y+2 for x in range(5) let y = x+1]
*Previous talks*
I've had almost exactly the same idea in June 2017, see subject "variable
assignment in functional context here: https://mail.python.org/
pipermail/python-ideas/2017-June/subject.html.
Currently this can
On 16 February 2018 at 12:19, rym...@gmail.com wrote:
> I don't know...to me this looks downright ugly and an awkward special case.
> It feels like it combines reading difficulty of inline assignment with the
> awkwardness of a magic word and the ugliness of using ?. Basically,
On Thu, Feb 15, 2018 at 10:13:37AM +, Jamie Willis wrote:
> 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
On 2/15/2018 8:37 PM, Chris Barker - NOAA Federal wrote:
Back to one of your examples:
[f(x) for x in [x]]
What does that mean???
for x in seq
Means iterate through seq, and assign each item to the name x.
If that seq has x in it — I’m not sure that is even legal python — the
scope in a
I don't know...to me this looks downright ugly and an awkward special case.
It feels like it combines reading difficulty of inline assignment with the
awkwardness of a magic word and the ugliness of using ?. Basically, every
con of the other proposals combined...
--
Ryan (ライアン)
Yoko Shimomura,
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
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
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 =
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,
On 15 February 2018 at 05:56, 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
>
A thought just occurred to me. Maybe we should just add a Boolean class to
numbers? It's a subclass of Integral, presumably. And normally only
builtins.bool is registered with it. But np.bool can be added at the same
point you register the other np integral types.
On Wed, Feb 14, 2018 at 10:23
On Thu, Feb 15, 2018 at 2:13 AM, Jamie Willis wrote:
> These laws define behaviour that is expected equivalent by users;
>
> [x for x in xs] = xs
>
OK -- that's the definition...
> [f(x) for x in [x]] = f(x)
>
well, not quite:
[f(x) for x in [x]] = [f(x)]
Hi fhsxfhsx, and welcome.
My comments below, interleaved with yours.
On Thu, Feb 15, 2018 at 01:56:44PM +0800, fhsxfhsx wrote:
[quoted out of order]
> And I hope the discussion could focus more on whether we should allow
> assigning temporary variables in comprehensions rather than how to
>
> Setting a new comprehension variable is not likely to be free, and may even be
> more costly than calling f(x) twice if f() is a cheap expression:
>
>[x+1 + some_func(x+1) for x in range(10)]
>
> could be faster than
>
>[y + some_func(y) for x in range(10) let y = x + 1]
A bit of a nit
15 matches
Mail list logo