[Python-ideas] A cute Python implementation of itertools.tee
k7hoven at gmail.com
Mon Apr 16 04:55:56 EDT 2018
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
> > 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?
> > (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
> > 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
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas