However, the implementation for both ntpath and posixpath can work with an Iterable just fine, since 3.6. At a glance, both implementations could be re-written without requiring random access and re-iteration, i.e. optimized to work in one go.
In my particular use-case I have a large collection of objects that contain paths. Materialization of the generator comprehension seems wasteful if it can be avoided.
It appears to be an unnecessarily strict requirement due to implementation detail. Current implementation will work for iterators as long as they non-empty. It can be trivially modified to allow empty iterators as well.
But I think I can reasonably rewrite ntpath and posibpath implementations to work in one-go, so the iterators can be truly supported instead of under-the-hood materialization.
To the contrary, I think that it happens to accept iterables by accident of implementation and we shouldnât commit all future implementations to the same implementation.
Does commonpath currently accept non-sequence iterables? This is a simple question of implementation, and currently the answer is âYesâ, with the very very small exception that it does a falsiness test before tuplifying, which could easily be tweaked.
Should commonpath be documented as accepting arbitrary iterables? IMO this is completely orthogonal, and I have no strong opinion on the matter.
Can commonpath be reimplemented to perform one pass over the input? Simple question of implementation, again, and really just a matter of performance.
Whatâs the advantage of doing precisely one pass over the input (as opposed to forcing it to a tuple and then using it any way it likes)? Are you passing vast numbers of paths, such that the multiple passes actually cost more than the cost of combining them would be? From my reading of the code, it does a few checks, then grabs the min and max of the sequence. Yes, those could be done simultaneously in a single pass, but it wouldnât really save much.
So of the three questions, one isnât a proposal, and Iâm -0 on the other two.
The first two need to be proven (which probably means writing the code), but the third is quite orthogonal; the current implementation can accept arbitrary iterables, because it just tuplifies straight away.