[Python-ideas] os.path.commonprefix: Yes that old chestnut.

[Paul Moore]

On 24 March 2015 at 15:32, Andrew Barnert <abarnert at yahoo.com> wrote:
> But you probably want to test it first, and make sure I thought through the stupid edge cases like no iterables or empty iterables, since that's just off the top of my head, and while tired and recovering from a cold to boot. :)

lol Understood. It's still cleaner than my one :-)

> Also, while I think this generic function is useful on its own merits, it doesn't solve the problem that started this thread--as pointed out by (I forget who), just using it on the string parts gives the wrong answer for Windows paths. Should there also be a recipe in the pathlib docs referencing the itertools recipe? (Is it even reasonable for a recipe in one module's docs to rely on a recipe in another's?) Or maybe, as Tal (I think) suggested, a better solution is to avoid the problem and use parents instead of parts, meaning you don't even need a common_prefix recipe, but a last_initial_match (although that's just last(common_prefix(*args)), so maybe that doesn't really matter.)

I still think there's a case for a pathlib.PurePath.common_prefix()
method, if we get consensus on the behaviour, so if we did that, I'd
probably grab the itertools recipe and use it as a private function in
pathlib. It feels mildly clumsy to have a private implementation of an
itertools recipe in a different stdlib module, but I don't think it's
a big enough deal to justify pushing for the function to be actually
added to itertools (which would involve rewriting in C, for a start).

Paul