Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 30/05/2018 17:05, Peter O'Connor wrote: On Thu, May 24, 2018 at 2:49 PM, Steven D'Aprano > wrote: On Thu, May 24, 2018 at 02:06:03PM +0200, Peter O'Connor wrote: > We could use given for both the in-loop variable update and the variable >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, May 24, 2018 at 2:49 PM, Steven D'Aprano wrote: > On Thu, May 24, 2018 at 02:06:03PM +0200, Peter O'Connor wrote: > > We could use given for both the in-loop variable update and the variable > > initialization: > >smooth_signal = [average given average=(1-decay)*average + decay*x >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 28 May 2018 at 10:17, Greg Ewing wrote: > Nick Coghlan wrote: > >> Aye, while I still don't want comprehensions to implicitly create new >> locals in their parent scope, I've come around on the utility of letting >> inline assignment targets be implicitly nonlocal

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Nick Coghlan wrote: Aye, while I still don't want comprehensions to implicitly create new locals in their parent scope, I've come around on the utility of letting inline assignment targets be implicitly nonlocal references to the nearest block scope. What if you're only intending to use it

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 26 May 2018 at 04:14, Tim Peters wrote: > [Peter O'Connor] > >> ... > >> We could use given for both the in-loop variable update and the variable > >> initialization: > >>smooth_signal = [average given average=(1-decay)*average + decay*x > >>

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Peter O'Connor] >> ... >> We could use given for both the in-loop variable update and the variable >> initialization: >>smooth_signal = [average given average=(1-decay)*average + decay*x >> for x in signal] given average=0. [Steven D'Aprano

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, May 24, 2018 at 02:06:03PM +0200, Peter O'Connor wrote: > To give this old horse a kick: The "given" syntax in the recent thread > could give a nice solution for the problem that started this thread. Your use-case is one of the motivating examples for PEP 572. Unless I'm confused, your

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

To give this old horse a kick: The "given" syntax in the recent thread could give a nice solution for the problem that started this thread. Instead of my proposal of: smooth_signal = [average := (1-decay)*average + decay*x for x in signal from average=0.] We could use given for both the

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 16 April 2018 at 10:49, Peter O'Connor wrote: > Are you able to show how you'd implement the moving average example with > your package? > Sure! The single pole IIR filter you've shown is implemented here:

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

In any case, although I find the magic variable-injection stuff quite strange, I like the decorator. Something like @scannable(average=0) # Wrap function so that it has a "scan" method which can be used to generate a stateful scan object def exponential_moving_average(average, x,

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Hi Danilo, The idea of decorating a function to show that the return variables could be fed back in in a scan form is interesting and could solve my problem in a nice way without new syntax. I looked at your code but got a bit confused as to how it works (there seems to be some magic where the

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 5 April 2018 at 13:52, Peter O'Connor wrote: > I was thinking it would be nice to be able to encapsulate this common type > of operation into a more compact comprehension. > > I propose a new "Reduce-Map" comprehension that allows us to write: > > signal =

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Wed, Apr 11, 2018 at 10:50 AM, Paul Moore wrote: > In particular, I'm happiest with the named moving_average() function, > which may reflect to some extent my lack of familiarity with the > subject area. I don't *care* how it's implemented internally - an > explicit loop

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> > It's worth adding a reminder here that "having more options on the > market" is pretty directly in contradiction to the Zen of Python - > "There should be one-- and preferably only one --obvious way to do > it". I've got to start minding my words more. By "options on the market" I more

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 11 April 2018 at 04:41, Steven D'Aprano wrote: >> > But in a way that more intuitively expresses the intent of the code, it >> > would be great to have more options on the market. >> >> It's worth adding a reminder here that "having more options on the >> market" is pretty

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Wed, Apr 11, 2018 at 1:41 PM, Steven D'Aprano wrote: > Personally, I still think the best approach here is a combination of > itertools.accumulate, and the proposed name-binding as an expression > feature: > > total = 0 > running_totals = [(total := total + x) for

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 2018-04-08 10:41, Kyle Lahnakoski wrote: For example before I read the docs on itertools.accumulate(list_of_length_N, func), here are the unknowns I see: It sounds like you're saying you don't like using functions because you have to read documentation. That may be so, but I don't have

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Tue, Apr 10, 2018 at 08:12:14PM +0100, Paul Moore wrote: > On 10 April 2018 at 19:25, Peter O'Connor wrote: > > Kyle Lahnakoski made a pretty good case for not using > > itertools.accumulate() earlier in this thread > > I wouldn't call it a "pretty good case". He

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Jacco van Dorp ] > I've sometimes thought that exhaust(iterator) or iterator.exhaust() would be > a good thing to have - I've often wrote code doing basically "call this > function > for every element in this container, and idc about return values", but find > myself using

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 10 April 2018 at 19:25, Peter O'Connor wrote: > Kyle Lahnakoski made a pretty good case for not using itertools.accumulate() > earlier in this thread I wouldn't call it a "pretty good case". He argued that writing *functions* was a bad thing, because the name of a

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 10/04/18 18:32, Steven D'Aprano wrote: On Tue, Apr 10, 2018 at 12:18:27PM -0400, Peter O'Connor wrote: [...] I added your coroutine to the freak show: Peter, I realise that you're a fan of functional programming idioms, and I'm very sympathetic to that. I'm a fan of judicious use of FP

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> > But even I find your use of dysphemisms like "freak show" for non-FP > solutions quite off-putting. Ah, I'm sorry, "freak show" was not mean to be disparaging to the authors or even the code itself, but to describe the variety of strange solutions (my own included) to this simple problem.

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Tue, Apr 10, 2018 at 12:18:27PM -0400, Peter O'Connor wrote: [...] > I added your coroutine to the freak show: Peter, I realise that you're a fan of functional programming idioms, and I'm very sympathetic to that. I'm a fan of judicious use of FP too, and while I'm not keen on your specific

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> > First, why a class would be a bad thing ? It's clear, easy to > understand, debug and extend. - Lots of reduntand-looking "frameworky" lines of code: "self._param_1 = param_1" - Potential for opaque state changes: Caller doesn't know if "y=my_object.do_something(x)" has any side-effect,

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Le 10/04/2018 à 00:54, Peter O'Connor a écrit : > Kyle, you sounded so reasonable when you were trashing > itertools.accumulate (which I now agree is horrible).  But then you go > and support Serhiy's madness:  "smooth_signal = [average for average in > [0] for x in signal for average in

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Greg Ewing writes: > Kyle Lahnakoski wrote: > > > Consider Serhiy Storchaka's elegant solution, which I reformatted for > > readability > > > >>smooth_signal = [ > >> average > >>for average in [0] > >>for x in signal > >> for average in [(1-decay)*average + decay*x] >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

I continue to find all this weird new syntax to create absurdly long one-liners confusing and mysterious. Python is not Perl for a reason. On Mon, Apr 9, 2018, 5:55 PM Peter O'Connor wrote: > Kyle, you sounded so reasonable when you were trashing >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Kyle, you sounded so reasonable when you were trashing itertools.accumulate (which I now agree is horrible). But then you go and support Serhiy's madness: "smooth_signal = [average for average in [0] for x in signal for average in [(1-decay)*average + decay*x]]" which I agree is clever, but

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 09/04/18 11:52, Rhodri James wrote: On 07/04/18 09:54, Cammil Taank wrote: Care to repeat those arguments? Indeed. *Minimal use of characters* Terseness is not necessarily a virtue.  While it's good not to be needlessly verbose, Python is not Perl and we are not trying to do

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 07/04/18 09:54, Cammil Taank wrote: Care to repeat those arguments? Indeed. *Minimal use of characters* Terseness is not necessarily a virtue. While it's good not to be needlessly verbose, Python is not Perl and we are not trying to do everything on one line. Overly terse code is

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> With the increased emphasis on iterators and generators in Python 3.x, > the lack of a simple expression level equivalent to "for item in > iterable: pass" is occasionally irritating, especially when > demonstrating behaviour at the interactive prompt. I've sometimes thought that

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Kyle Lahnakoski wrote: Consider Serhiy Storchaka's elegant solution, which I reformatted for readability smooth_signal = [ average for average in [0] for x in signal for average in [(1-decay)*average + decay*x] ] "Elegant" isn't the word I would use, more like "clever". Rather

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 2018-04-05 21:18, Steven D'Aprano wrote: > (I don't understand why so many people have such an aversion to writing > functions and seek to eliminate them from their code.) > I think I am one of those people that have an aversion to writing functions! I hope you do not mind that I attempt

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 7 April 2018 at 09:50, Steven D'Aprano wrote: > On Fri, Apr 06, 2018 at 08:06:45AM -0700, Guido van Rossum wrote: > >> Please join the PEP 572 discussion. The strongest contender currently is `a >> := f()` and for good reasons. > > Where has that discussion moved to? The

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> Care to repeat those arguments? Indeed. *Minimal use of characters* The primary benefit for me would be the minimal use of characters, which within list comprehensions I think is not an insignificant benefit: stuff = [[(f(x) as y), x/y] for x in range(5)] # seems quite syntactically

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Sat, Apr 7, 2018 at 9:50 AM, Steven D'Aprano wrote: > On Fri, Apr 06, 2018 at 08:06:45AM -0700, Guido van Rossum wrote: > >> Please join the PEP 572 discussion. The strongest contender currently is `a >> := f()` and for good reasons. > > Where has that discussion moved to?

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 06, 2018 at 08:06:45AM -0700, Guido van Rossum wrote: > Please join the PEP 572 discussion. The strongest contender currently is `a > := f()` and for good reasons. Where has that discussion moved to? The threads on python-ideas seem to have gone quiet, and the last I heard you said

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 06, 2018 at 03:27:45PM +, Cammil Taank wrote: > I'm not sure if my suggestion for 572 has been considered: > > ``name! expression`` > > I'm curious what the pros and cons of this form would be (?). I can't see any pros for it. In what way is ! associated with assignment or

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Seems to me it's much more obvious that "name:=expression" is assigning expression to name than "name!expression". The ! is also confusing because "!=" means "not equals", so the "!" symbol is already sort of associated with "not" On Fri, Apr 6, 2018 at 11:27 AM, Cammil Taank

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

I'm not sure if my suggestion for 572 has been considered: ``name! expression`` I'm curious what the pros and cons of this form would be (?). My arguments for were in a previous message but there do not seem to be any responses to it. Cammil On Fri, 6 Apr 2018, 16:14 Guido van Rossum,

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor wrote: > Hi all, thank you for the feedback. I laughed, I cried, and I learned. > You'll be a language designer yet. :-) > However, it looks like I'd be fighting a raging current if I were to try > and push this

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Ah, ok, I suppose that could easily lead to typo-bugs. Ok, then I agree that "a:=f()" returning a is better On Fri, Apr 6, 2018 at 10:53 AM, Eric Fahlgren wrote: > On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor > wrote: > >> 3) The idea

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor wrote: > 3) The idea that an assignment operation "a = f()" returns a value (a) is > already consistent with the "chained assignment" syntax of "b=a=f()" (which > can be thought of as "b=(a=f())"). I don't know why we

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Hi all, thank you for the feedback. I laughed, I cried, and I learned. I looked over all your suggestions and recreated them here: https://github.com/petered/peters_example_code/blob/master/peters_example_code/ways_to_skin_a_cat.py I still favour my (y = f(y, x) for x in xs from y=initializer)

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

05.04.18 19:52, Peter O'Connor пише: I propose a new "Reduce-Map" comprehension that allows us to write: signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1)for iin range(1000)] smooth_signal = [average = (1-decay)*average + decay*xfor xin signalfrom average=0.] Using currently

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 06, 2018 at 11:02:30AM +1000, Chris Angelico wrote: > On Fri, Apr 6, 2018 at 10:37 AM, Steven D'Aprano wrote: [...] > > All we need now is a way to feed in the initial value for average. And > > that could be as trival as assigning a local name for it: > > > >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, Apr 05, 2018 at 12:52:17PM -0400, Peter O'Connor wrote: > I propose a new "Reduce-Map" comprehension that allows us to write: > > signal = [math.sin(i*0.01) + random.normalvariate(0, 0.1) for i in > range(1000)] > smooth_signal = [average = (1-decay)*average + decay*x for x in signal >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 05:37 PM, Steven D'Aprano wrote: On Thu, Apr 05, 2018 at 05:31:41PM -0700, Ethan Furman wrote: [snip unkind words] Be fair. Strip out the last "from average = 0" and we have little that isn't either in Python or is currently being proposed elsewhere. Ugh. Thanks for

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 6, 2018 at 10:37 AM, Steven D'Aprano wrote: > On Thu, Apr 05, 2018 at 05:31:41PM -0700, Ethan Furman wrote: >> On 04/05/2018 03:24 PM, Peter O'Connor wrote: >> >> >Well, whether you factor out the loop-function is a separate issue. Lets >> >say we do: >> > >> >

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Fri, Apr 06, 2018 at 10:29:19AM +1000, Steven D'Aprano wrote: > - That you call it "MapReduce" while apparently doing something > different from what other people call MapReduce: Actually, no you don't -- you call it "Reduce-Map". Sorry, my mistake. -- Steve

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, Apr 05, 2018 at 05:31:41PM -0700, Ethan Furman wrote: > On 04/05/2018 03:24 PM, Peter O'Connor wrote: > > >Well, whether you factor out the loop-function is a separate issue. Lets > >say we do: > > > > smooth_signal = [average = compute_avg(average, x) for x in signal > > from

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, Apr 05, 2018 at 06:24:25PM -0400, Peter O'Connor wrote: > Well, whether you factor out the loop-function is a separate issue. Lets > say we do: > > smooth_signal = [average = compute_avg(average, x) for x in signal from > average=0] > > Is just as readable and maintainable as

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 03:24 PM, Peter O'Connor wrote: Well, whether you factor out the loop-function is a separate issue. Lets say we do: smooth_signal = [average = compute_avg(average, x) for x in signal from average=0] Is just as readable and maintainable as your expanded version, but saves

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On Thu, Apr 5, 2018, 5:32 PM Peter O'Connor wrote: > I find this a bit awkward, and maintain that it would be nice to have this > as a built-in language construct to do this natively. You have to admit: > > smooth_signal = [average = (1-decay)*average + decay*x

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 5 April 2018 at 22:26, Peter O'Connor wrote: > I find this a bit awkward, and maintain that it would be nice to have this > as a built-in language construct to do this natively. You have to admit: > > smooth_signal = [average = (1-decay)*average + decay*x for x

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Ah, that's nice, I didn't know that itertools.accumulate now has an optional "func" parameter. Although to get the exact same behaviour (output the same length as input) you'd actually have to do: smooth_signal = itertools.islice(itertools.accumulate([initial_average] + signal, compute_avg),

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

> On 2018 Apr 5 , at 12:52 p, Peter O'Connor wrote: > > Dear all, > > In Python, I often find myself building lists where each element depends on > the last. This generally means making a for-loop, create an initial list, > and appending to it in the loop, or

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 04/05/2018 09:52 AM, Peter O'Connor wrote: [snip html code snippets] Please don't use html markup. The code was very difficult to read. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

On 05/04/18 17:52, Peter O'Connor wrote: Dear all, In Python, I often find myself building lists where each element depends on the last. This generally means making a for-loop, create an initial list, and appending to it in the loop, or creating a generator-function. Both of these feel more

[Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

Dear all, In Python, I often find myself building lists where each element depends on the last. This generally means making a for-loop, create an initial list, and appending to it in the loop, or creating a generator-function. Both of these feel more verbose than necessary. I was thinking it