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 range(
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
> was similar to the SQL
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, thos
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 having a special variable
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 th
On Mon, Oct 24, 2016 at 10:22 AM, 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 having a special variable
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 iter
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...
>
> But there should be one
>
> 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 (
Sure, a better last() should try to index into it[-1] first as an
efficiency. And there are lots of iterators where the last element is
predictable without looking through all the prior items. I know the last
item of itertools.repeat(7, sys.maxsize) without having to loop for hours.
But the genera
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:
it = iterations.chain([s
>
> 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 coun
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
>
> 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 co
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 D'Apr
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 iteratab
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
> s
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 reduction/accumulation
>
> 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
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
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
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().
>
>
22 matches
Mail list logo
