[Koos Zevenhoven <k7hoven@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.

> 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.