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