[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 <wink>).
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4