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