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] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

> On Apr 6, 2018, at 9:06 PM, Tim Peters wrote: > >> >>What is this code trying to accomplish? > > It's quite obviously trying to bias the reader against the proposal by > presenting a senseless example ;-) FWIW, the example was not from me. It was provided by

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

On 7 April 2018 at 08:44, Raymond Hettinger wrote: > Agreed that the "chain([x], it)" step is obscure. That's a bit of a bummer > -- one of the goals for the itertools module was to be a generic toolkit for > chopping-up, modifying, and splicing iterator streams

Re: [Python-ideas] Is there any idea about dictionary destructing?

This would be a very handy feature, but Coconut (which is just python with some extra functional-style features) also has support for this kind of pattern-matching: http://coconut-lang.org ​Since Coconut will compile to Python (2 or 3) you can just write in Coconut and use the resulting code in

[Python-ideas] Is there any idea about dictionary destructing?

We know that Python support the destructing of iterable objects. m_iter = (_ for _ in range(10)) a, *b, c = m_iter That's pretty cool! It's really convenient when there're many corner cases to handle with iterable collections. However destructing in Python could be more convenient if we support

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

Nick, sorry, but your arguments still make little sense to me. I think you're pushing an analogy between `sum()` details and `accumulate()` way too far, changing a simple idea into a needlessly complicated one. `accumulate()` can do anything at all it wants to do with a `start` argument (if

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

On 8 April 2018 at 14:31, Guido van Rossum wrote: > Given that two respected members of the community so strongly disagree > whether accumulate([], start=0) should behave like accumulate([]) or like > accumulate([0]), maybe in the end it's better not to add a start argument. >

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

Top-posting just to say I agree with Nick's bottom line (changing the name to `first_result=`). I remain just +0.5, although that is up a notch from yesterday's +0.4 ;-) --- nothing new below --- On Sun, Apr 8, 2018 at 12:19 AM, Nick Coghlan wrote: > On 8 April 2018 at

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

On 8 April 2018 at 15:00, Tim Peters wrote: > `accumulate()` accepts any two-argument function. > itertools.accumulate([1, 2, 3], lambda x, y: str(x) + str(y)) > list(_) > [1, '12', '123'] > > Arguing that it "has to do" something exactly the way `sum()` happens >

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

Just a nit here: [Tim] >> ... >> Arguing that it "has to do" something exactly the way `sum()` happens >> to be implemented just doesn't follow - not even if they happen to >> give the same name to an optional argument. If the function were >> named `accumulate_sum()`, and restricted to numeric

Re: [Python-ideas] Is there any idea about dictionary destructing?

And this should print: 'some data' 1 2 3 On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof < nikolasrvanderh...@gmail.com> wrote: > This would be a very handy feature, but Coconut (which is just python with > some extra functional-style features) also has support for this kind of >

Re: [Python-ideas] Is there any idea about dictionary destructing?

Although that particular example once compiled to python will generate many many lines of code: ​ On Sat, Apr 7, 2018 at 4:17 PM, Nikolas Vanderhoof < nikolasrvanderh...@gmail.com> wrote: > And this should print: > > 'some data' > 1 > 2 > 3 > > On Sat, Apr 7, 2018 at 4:16 PM, Nikolas Vanderhoof

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

... [Tim] >> Later: >> >>def coll(SHIFT=24): >>... >>from itertools import accumulate, chain, cycle >>... >>LIMIT = 1 << SHIFT >>... >>abc, first, deltas = buildtab(SHIFT, LIMIT) >>... >>for num in accumulate(chain([first],

Re: [Python-ideas] Is there any idea about dictionary destructing?

There was a long thread last year on a subject, titled "Dictionary destructing and unpacking.": https://mail.python.org/pipermail/python-ideas/2017-June/045963.html You might want to read through it and see what ideas and problems were raised then. In that discussion, there's also a link to

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] Start argument for itertools.accumulate() [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin]

[Nick Coghlan ] > I didn't have a strong opinion either way until Tim mentioned sum() > and then I went and checked the docs for both that and for accumulate. > > First sentence of the sum() docs: > > Sums *start* and the items of an *iterable* from left to right and >

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

On 8 April 2018 at 08:09, Tim Peters wrote: [Raymond wrote]: >> The docs probably need another recipe to show this pattern: >> >> def prepend(value, iterator): >> "prepend(1, [2, 3, 4]) -> 1 2 3 4" >> return chain([value], iterator) > > +1.

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

On 8 April 2018 at 13:17, Tim Peters wrote: > [Nick Coghlan ] >> So I now think that having "start" as a parameter to one but not the >> other, counts as a genuine API discrepancy. > > Genuine but minor ;-) Agreed :) >> Providing start to accumulate

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

Given that two respected members of the community so strongly disagree whether accumulate([], start=0) should behave like accumulate([]) or like accumulate([0]), maybe in the end it's better not to add a start argument. (The disagreement suggests that we can't trust users' intuition here.) On