os.path.commonprefix inadequacies

Mats Wichmann xyzmats at laplaza.org
Fri Aug 3 15:29:35 EDT 2001


On Tue, 31 Jul 2001 16:59:22 -0500, Skip Montanaro <skip at pobox.com>
wrote:

:
:    Dean> The os.path.commonprefix function at first glance seems like a
:    Dean> useful function: to find a common ancestor of a bunch of
:    Dean> paths.
:
:I tried to get this sort of change adopted two years ago, but was unable to
:convince people that it should operate on path elements instead of strings.
:In fact, I actually updated the relevant bits of code in CVS but had to
:retract the changes when the semantic change broke something of Mark
:Hammond's.  My argument was that the common filesystem prefix of these two
:paths
:
:    /home/sally
:    /home/sam
:
:should be "/home/" (or "/home"), not "/home/sa".  

Well, I wasn't listening in 1999, but I certainly agree.  If you want
a routine that works as this one is described, it should be a string
method and work on arbitrary strings.  If it's going to live in
os.path, it should work on the pathname-component level only.

Maybe it's time to try again, now that there's a warning framework to
introduce a change gnetly.

Mats Wichmann

(Anti-spam stuff: to reply remove the "xyz" from the
address xyzmats at laplaza.org. Not that it helps much...)



More information about the Python-list mailing list