[Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

2018-02-15 Thread Nick Coghlan
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 ==

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Robert Vanden Eynde
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

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

2018-02-15 Thread Nick Coghlan
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,

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Steven D'Aprano
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

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Terry Reedy
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

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

2018-02-15 Thread rym...@gmail.com
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,

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread 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

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Stephan Houben
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

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread 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 =

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Evpok Padding
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,

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Paul Moore
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 >

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

2018-02-15 Thread Guido van Rossum
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

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Chris Barker
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)]

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Steven D'Aprano
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 >

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-15 Thread Chris Barker - NOAA Federal
> 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