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

[Peter O'Connor ] > Ok, so it seems everyone's happy with adding an initial_value argument. Heh - that's not clear to me ;-) > Now, I claim that while it should be an option, the initial value should NOT > be returned by default. (i.e. the returned generator should

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

* correction to brackets from first example: def iter_cumsum_tolls_from_day(day, toll_amount_so_far): return accumulate(get_tolls_from_day(day), initial=toll_amount_so_far) On Mon, Apr 9, 2018 at 11:55 PM, Peter O'Connor wrote: > Ok, so it seems everyone's

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

Ok, so it seems everyone's happy with adding an initial_value argument. Now, I claim that while it should be an option, the initial value should NOT be returned by default. (i.e. the returned generator should by default yield N elements, not N+1). Example: suppose we're doing the toll booth

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

[Tim] >> while we have N numbers, there are N+1 slice indices. So >> accumulate(xs) doesn't quite work. It needs to also have a 0 inserted >> as the first prefix sum (the empty prefix sum(xs[:0]). >> >> Which is exactly what a this_is_the_initial_value=0 argument would do >> for us. [Greg Ewing

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] Is there any idea about dictionary destructing?

On 9 April 2018 at 22:10, Brett Cannon wrote: > > > On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote: >> >> we could even call this approach a name such as "function call". > > > The harsh sarcasm is not really called for. Indeed - on rereading, I

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

Tim Peters wrote: while we have N numbers, there are N+1 slice indices. So accumulate(xs) doesn't quite work. It needs to also have a 0 inserted as the first prefix sum (the empty prefix sum(xs[:0]). Which is exactly what a this_is_the_initial_value=0 argument would do for us. In this case,

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

On Mon, 9 Apr 2018 at 05:18 Joao S. O. Bueno wrote: > I have an idea for an inovative, unanbiguous, straightforward and > backwards compatible syntax for that, > that evena llows one to pass metadata along the operation so that the > results can be tweaked acording > to

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

Peter O'Connor wrote: The behaviour where the first element of the return is the same as the first element of the input can be weird and confusing. E.g. compare: >> list(itertools.accumulate([2, 3, 4], lambda accum, val: accum-val)) [2, -1, -5] >> list(itertools.accumulate([2, 3, 4], lambda

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

Woo hoo! Another coincidence. I just happened to be playing with this problem today: You have a large list - xs - of N numbers. It's necessary to compute slice sums sum(xs[i:j]) for a great many slices, 0 <= i <= j <= N. For concreteness, say xs is a time series representing a toll

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

On Friday, April 6, 2018 at 9:03:05 PM UTC-4, Raymond Hettinger wrote: > > > On Friday, April 6, 2018 at 8:14:30 AM UTC-7, Guido van Rossum wrote: > > On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor > wrote: > >> So some more humble proposals would be: > >> > >> 1)

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

[Tim] >> Then why was [accumulate] generalized to allow any 2-argument function? [Raymond] > Prior to 3.2, accumulate() was in the recipes section as pure Python > code. It had no particular restriction to numeric types. > > I received a number of requests for accumulate() to be promoted > to a

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

Also Tim Peter's one-line example of: print(list(itertools.accumulate([1, 2, 3], lambda x, y: str(x) + str(y I think makes it clear that itertools.accumulate is not the right vehicle for this change - we should make a new itertools function with a required "initial" argument. On Mon, Apr 9,

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

It seems clear that the name "accumulate" has been kind of antiquated since the "func" argument was added and "sum" became just a default. And people seem to disagree about whether the result should have a length N or length N+1 (where N is the number of elements in the input iterable). The

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

No worries, already implemented features happens so often in this list that there's a story about Guido going back in a time machine to implement them ;-) Just wanted to check that I had understood what you suggested correctly On 9 April 2018 at 12:42, Andrés Delfino wrote:

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

I have an idea for an inovative, unanbiguous, straightforward and backwards compatible syntax for that, that evena llows one to pass metadata along the operation so that the results can be tweaked acording to each case's needs. What about: new_data = dict_feed({ "direct": "some data",

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

I'm sorry that I didn't send a copy of the discussions here. -- Forwarded message -- From: Thautwarm Zhao Date: 2018-04-09 1:24 GMT+08:00 Subject: Re: [Python-ideas] Is there any idea about dictionary destructing? To: "Eric V. Smith"

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

Sorry, I didn't know that kwargs unpacking in dictionaries displays don't raise a TypeError exception. On Mon, Apr 9, 2018 at 8:23 AM, Daniel Moisset wrote: > In which way would this be different to {**mapping1, **mapping2, > **mapping3} ? > > On 8 April 2018 at 22:18,

Re: [Python-ideas] Accepting multiple mappings as positional arguments to create dicts

In which way would this be different to {**mapping1, **mapping2, **mapping3} ? On 8 April 2018 at 22:18, Andrés Delfino wrote: > Hi! > > I thought that maybe dict could accept several mappings as positional > arguments, like this: > > class Dict4(dict): >> def

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

On 9 April 2018 at 14:38, Raymond Hettinger wrote: >> On Apr 8, 2018, at 6:43 PM, Tim Peters wrote: >> In short, for _general_ use `accumulate()` needs `initial` for exactly >> the same reasons `reduce()` needed it. > > The reduce() function had

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] PEP 572: Statement-Local Name Bindings, take three!

On 9 April 2018 at 01:01, Steven D'Aprano wrote: > On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote: > >> I was writing a new stdlib test case today, and thinking about how I >> might structure it differently in a PEP 572 world, and realised that a >> situation

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

Raymond Hettinger wrote: I don't want to overstate the case, but I do think a function signature that offers a "first_value" option is an invitation to treat the first value as being distinct from the rest of the data stream. I conjecture that the initial value is *always* special, and the

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