[Python-bugs-list] [Bug #112288] os.path.commonprefix behaviour change.

[noreply@sourceforge.net]

Bug #112288, was updated on 2000-Aug-18 22:48
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: None
Bug Group: None
Priority: 6
Summary: os.path.commonprefix behaviour change.

Details: From python-dev:

On 1.5.2, the behaviour was:
>>> os.path.commonprefix(["../foo/bar", "../foo/spam"])
'../foo/'

While since the change we have:
'../foo'

Note that the trailing slash has been dropped.

[snip existing code that was broken by this change - much debate on python-dev ensues about which is the more desirable behaviour.]

Tim adds:
I agree this is Bad Damage, and should be fixed before 2.0b1 goes out.  Can you enter a bug report?

[more debate about what is the better behaviour, and that the old way was obviously broken]

Tim again:
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>).

And Tim yet again:
When the code and the docs have matched for more than 6 years, there is no bug by any rational definition of the term, and you can be certain that changing the library semantics then will break existing code.  Presuming to change it anyway is developer arrogance of the worst kind, no matter how many developers cheer it on.  The docs are a
contract, and if they were telling the truth, we have a responsibility to stand by them


Follow-Ups:

Date: 2000-Aug-19 00:43
By: tim_one

Comment:
A couple more points:

+ My only objection is to changing what the function does.  I now know for a fact that some people at my last job were using at *as* a string function, just as it was documented to work.  This means there are almost certainly many more people who will get burned too if commonprefix changes.

+ I wholly agree that it's not particularly useful for path manipulation, and encourage adding a *new* function that is useful for that.

+ Although Python-Dev doesn't seem able to agree yet on exactly what such a function should do (esp. whether to keep or toss trailing path separators).

+ I am not the BDFL.  If Guido wants to piss off users by embracing the current incompatibility as-is, that's his call.  But in that case this bug should morph into a gripe about the now-inaccurate library docs.

-------------------------------------------------------

Date: 2000-Aug-22 10:53
By: montanaro

Comment:
changes to posixpath.py, ntpath.py and dospath.py were reverted.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112288&group_id=5470