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, every
> con of the
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 interacti
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 easi
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 co
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, ryo
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 ==
T
> 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 —
I’d like to clarify that f(x) was indeed meant to be a sequence. As per
monad law:
*do* { y *<-* *do* { x *<-* m;
f x
}
g y
}
===
*do* { x *<-* m;
y *<-* f x;
g y
}
I think you might have misunderstood the types of things; f: Function[
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
> s
I’d like to clarify that f(x) was indeed meant to be a sequence. As per monad
law:
do { y <- do { x <- m;
f x
}
g y
}
===
do { x <- m;
y <- f x;
g y
}
I think you might have misunderstood the types of things; f: Function[a,
List[b]] a
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)]
Using x in two places where they m
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 AM,
Yes, this is used in combination dynamic type checking, currently using
enforce (https://github.com/RussBaz/enforce ) but I know that others exist
(pytypes in particular)
As per examples…all utility functions that we write that are receiving a number
or a boolean in their parameters are now wr
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 per
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
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
> we don't need to ha
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, j
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_
18 matches
Mail list logo
