Re: [Python-ideas] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

[Raymond Hettinger ] > ... > Q. How readable is the proposed code? > A. Look at the following code and ask yourself what it does: > > accumulate(range(4, 6), operator.mul, start=6) > >Now test your understanding: > > How many values are emitted? 3

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] [Distutils] Pypi private repo's

On 5 April 2018 at 07:58, Jannis Gebauer wrote: > What if there was some kind of “blessed” entity that runs these services and > puts the majority of the revenue into a fund that funds development on PyPi > (maybe trough the PSF)? Having a wholly owned for-profit subsidiary that

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