[Python-Dev] Re: os.path.commonprefix breakage (original) (raw)

Tim Peters tim_one@email.msn.com
Thu, 17 Aug 2000 02:41:29 -0400

[Greg Ewing]

I've just looked at the 1.5.2 docs and realised that this is what it says it does! So it's right according to the docs, although it's obviously useless as a pathname manipulating function.

[Fred Drake]

I think we should now fix the docs; Skip's right about the desired functionality.

Oddly enough, I don't: commonprefix worked exactly as documented for at least 6 years and 5 months (which is when CVS shows Guido checking in ntpath.py with the character-based functionality), and got out of synch with the docs about 5 weeks ago when Skip changed to this other algorithm. Since the docs did match the code, there's no reason to believe the original author was confused, and no reason to believe users aren't relying on it (they've had over 6 years to gripe ).

I think it's wrong to change what released code or docs do or say in non-trivial ways when they weren't ever in conflict. We have no idea who may be relying on the old behavior! Bitch all you like about MarkH's test case, it used to work, it doesn't now, and that sucks for the user.

I appreciate that some other behavior may be more useful more often, but if you can ever agree on what that is across platforms, it should be spelled via a new function name ("commonpathprefix" comes to mind), or optional flag (defaulting to "old behavior") on commonprefix (yuck!). BTW, the presence or absence of a trailing path separator makes a big difference to many cmds on Windows, and you can't tell me nobody isn't currently doing e.g.

commonprefix(["blah.o", "blah", "blah.cpp"])

on Unix either.