On 23 March 2015 at 21:33, Gregory P. Smith
+1 pathlib would be the appropriate place for the correctly behaving function to appear.
OK, so here's a question. What actual use cases exist for a common_prefix function? The reason I ask is that I'm looking at some of the edge cases, and the obvious behaviour isn't particularly clear to me. For example, common_prefix('a/b/file.c', 'a/b/file.c'). The common prefix is obviously 'a/b/file.c' - but I can imagine people *actually* wanting the common *directory* containing both files. But taken literally, that's only possible if you check the filesystem, so it would no longer be a PurePath operation. And what about common_prefix('foo/bar', '../here/foo')? Or common_prefix('bar/baz', 'foo/../bar/baz')? Pathlib avoids collapsing .. because the meaning could change in the face of symlinks. I believe the same applies here. Maybe you need to call resolve() before doing the common prefix operation (but that gives an absolute path). With the above limitations, would a common_prefix function actually help typical use cases? In my experience, doing list operations on pathobj.parts is often simple enough that I don't need specialised functions like common_prefix... Getting the edge cases right is fiddly enough for common_prefix that a specialised function is a reasonable idea, but only if the "obvious" behaviour is clear. If there's a lot of conflicting possibilities, maybe a recipe in the docs would be a better option. Paul