Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
The proposal is mostly about scan/accumulate. Reduce/fold is a "corollary", as it's just the last value of a scan. The idea is to have a way of using the previous iteration output inside a list comprehension (and anything alike). That is, to make them recursive. last([abs(prev - x) for x in

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Chris Angelico
On Mon, Oct 24, 2016 at 11:29 AM, Steven D'Aprano wrote: > In fairness I am sick and if I were well I may have been able to keep > this straight in my head, but calling the variable "prev" is actively > misleading. I was mislead, and (I think) Chris who just suggested this >

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Steven D'Aprano
On Sun, Oct 23, 2016 at 02:10:42PM -0200, Danilo J. S. Bellini wrote: > > > > Ah, that makes SIX existing solutions. Do we need a seventh? > > It might have dozens of solutions, perhaps an infinity of solutions. > Brainfuck and assembly can be used, or even turing machine instructions... No,

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread David Mertz
On Sun, Oct 23, 2016 at 4:22 PM, Steven D'Aprano wrote: > Right. But you're missing the point of Danilo's proposal. He isn't > asking for a function to "jump to the end" of an iterator. Look at his > example. The word "last" is a misnomer: he seems to me talking > about

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Steven D'Aprano
On Mon, Oct 24, 2016 at 10:22:32AM +1100, Steven D'Aprano wrote: > On Sun, Oct 23, 2016 at 08:47:12AM -0700, David Mertz wrote: > > Consuming the iterator is *necessary* to get the last item. There's no way > > around that. > > > > Obviously, you could itertools.tee() it first if you don't mind

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Steven D'Aprano
On Sun, Oct 23, 2016 at 08:47:12AM -0700, David Mertz wrote: > Consuming the iterator is *necessary* to get the last item. There's no way > around that. > > Obviously, you could itertools.tee() it first if you don't mind the cache > space. But there cannot be a generic "jump to the end" of an

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Paul Moore
On 23 October 2016 at 17:10, Danilo J. S. Bellini wrote: >> Ah, that makes SIX existing solutions. Do we need a seventh? > > It might have dozens of solutions, perhaps an infinity of solutions. > Brainfuck and assembly can be used, or even turing machine instructions...

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
> > I would have preferred this signature to start with, but it's easy to > wrap. > Indeed, but a default value for the first argument requires a default value for all arguments. It's a syntax error, but I agree a "range-like" signature like that would be better. My reference scan implementation

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread David Mertz
On Oct 23, 2016 9:12 AM, "Danilo J. S. Bellini" wrote: Actually, itertools.accumulate and functools.reduce have their parameters reversed, and accumulate doesn't have a "start" parameter. def accumulate2(fn=operator.add, it, start=None): if start is not None:

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
> > Ah, that makes SIX existing solutions. Do we need a seventh? It might have dozens of solutions, perhaps an infinity of solutions. Brainfuck and assembly can be used, or even turing machine instructions... But there should be one, and preferably only one, OBVIOUS way to do it. Readability

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Steven D'Aprano
On Sun, Oct 23, 2016 at 12:57:10PM -0200, Danilo J. S. Bellini wrote: > The idea is to let generator expressions and list/set comprehensions have a > clean syntax to access its last output. That would allow them to be an > alternative syntax to the scan higher-order function [1] (today implemented

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
> > Of course. But if you want last(), why not just spell the utility function > as I did? [...] > I'm not against a general "last", I just said the main idea of this thread is the access to the previous iteration output in a list/set/dict comprehension or generator expression. > Actually, your

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread David Mertz
Consuming the iterator is *necessary* to get the last item. There's no way around that. Obviously, you could itertools.tee() it first if you don't mind the cache space. But there cannot be a generic "jump to the end" of an iterator without being destructive. On Oct 23, 2016 8:43 AM, "Steven

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Steven D'Aprano
On Sun, Oct 23, 2016 at 08:37:07AM -0700, David Mertz wrote: > Of course. But if you want last(), why not just spell the utility function > as I did? I.e. as a function: > > def last(it): > for item in it: > pass > return item > > That works fine for any

Re: [Python-ideas] Easily remove characters from a string.

2016-10-23 Thread Steven D'Aprano
On Sat, Oct 22, 2016 at 03:34:23PM +0700, Simon Mark Holland wrote: > Having researched this as heavily as I am capable with limited experience, > I would like to suggest a Python 3 equivalent to string.translate() that > doesn't require a table as input. Maybe in the form of str.stripall() or >

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread David Mertz
Of course. But if you want last(), why not just spell the utility function as I did? I.e. as a function: def last(it): for item in it: pass return item That works fine for any iteratable (including a list, array, etc), whether or not it's a

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
> > What is `last(inf_iter)`. E.g `last(count())`. The "last" is just a helper function that gets the last value of an iterable. On sequences, it can be written to get the item at index -1 to avoid traversing it. Using it on endless iterables makes no sense. This makes it clear that is the users

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread David Mertz
What is `last(inf_iter)`. E.g `last(count())`. To me, the obvious spelling is: for last in it: pass doSomething(last) This makes it clear that is the users job to make sure `it` terminates. There's no general way to get the last item without looking through all the earlier ones. On Oct

[Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-10-23 Thread Danilo J. S. Bellini
The idea is to let generator expressions and list/set comprehensions have a clean syntax to access its last output. That would allow them to be an alternative syntax to the scan higher-order function [1] (today implemented in the itertools.accumulate function), which leads to an alternative way to

Re: [Python-ideas] Easily remove characters from a string.

2016-10-23 Thread M.-A. Lemburg
On 22.10.2016 10:34, Simon Mark Holland wrote: > Having researched this as heavily as I am capable with limited experience, > I would like to suggest a Python 3 equivalent to string.translate() that > doesn't require a table as input. Maybe in the form of str.stripall() or > str.replaceall(). >