[Python-ideas] A cute Python implementation of itertools.tee

[Koos Zevenhoven]

On Mon, Apr 16, 2018 at 12:06 AM, Tim Peters <tim.peters at gmail.com> wrote:

> [Koos Zevenhoven <k7hoven at gmail.com>]
> >.... It's definitely possible to write the above in a more
> > readable way, and FWIW I don't think it involves "assignments as
> > expressions".
>
> Of course it is.  The point was brevity and speed, not readability.
> It was presented partly as a puzzle :-)
>
> >> What I find kind of hilarious is that it's no help at all as a
> >> prototype for a C implementation:  Python recycles stale `[next(it),
> >> None]` pairs all by itself, when their internal refcounts fall to 0.
> >> That's the hardest part.
>
> > Why can't the C implementation use Python refcounts? Are you talking
> about
> > standalone C code?
>
> Yes, expressing the algorithm in plain old C, not building on top of
> (say) the Python C API.
>
>
​There must have been a reason why pseudo code was "invented".​


> > Or perhaps you are thinking about overhead?
>
> Nope.
>
>
> > (In PEP 555 that was not a concern, though). Surely it would make sense
> > to reuse the refcounting code that's already there. There are no cycles
> > here, so it's not particulaly complicated -- just duplication.
> >
> > Anyway, the whole linked list is unnecessary if the iterable can be
> iterated
> > over multiple times.
>
> If the latter were how iterables always worked, there would be no need
> for tee() at all.  It's tee's _purpose_ to make it possible for
> multiple consumers to traverse an iterable's can't-restart-or-even
> -go-back result sequence each at their own pace.
>

​Yes. (I'm not sure which is easier, going back or starting from the
beginning)

-- Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180416/14fa4636/attachment-0001.html>