<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 7 Nov, 2012, at 3:05, Bruce Leban <<a href="mailto:bruce@leapyear.org">bruce@leapyear.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>It would be nice if in conjunction with this os.path.commonprefix is renamed as string.commonprefix with the os.path.commonprefix kept for backwards compatibility (and deprecated).</div><div><br></div><div>

more inline</div><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 7:49 AM, Ronald Oussoren <span dir="ltr"><<a href="mailto:ronaldoussoren@mac.com" target="_blank">ronaldoussoren@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On 6 Nov, 2012, at 16:27, Serhiy Storchaka <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>> wrote:<br>> What should be a common prefix of '/var/log/apache2' and '/var//log/mysql'?<br>


</div>/var/log<br>
<div class="im"><br>
> What should be a common prefix of '/usr' and '//usr'?<br>
</div>/usr<br>
<div class="im"><br>
> What should be a common prefix of '/usr/local/' and '/usr/local/'?<br>
</div>/usr/local<br>
<div class="im"><br></div></blockquote><div>It appears that you want the result to never include a trailing /. However, you've left out one key test case:</div><div><br></div><div>What is <font face="courier new, monospace">commonpath('/usr', '/var')</font>?</div>

<div><br></div><div>It seems to me that the only reasonable value is <font face="courier new, monospace">'/'</font>.</div></div></blockquote><div><br></div>I agree</div><div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>If you change the semantics so that it either (1) it always always includes a trailing / or (2) it includes a trailing slash if the two paths have it in common, then you don't have the weirdness that in this case it returns a slash and in others it doesn't. I am slightly inclined to (1) at this point.</div></div></blockquote><div><br></div>I'd prefer to only have a path seperator at the end when it has semantic meaning. That would mean that only the root of a filesystem tree ("/" on Unix, but also "C:\" and "<a href="smb://server/share/">\\server\share\</a>" on Windows) have a separator and the end.</div><div><br><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>It would also be a bit surprising that there are cases where commonpath(a,a) != a.</div></div></blockquote><div><br></div>That's already true, commonpath('/usr//bin', '/usr//bin') would be  '/usr/bin' and not '/usr//bin'.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<div class="im">
> What should be a common prefix of '/usr/local/' and '/usr/local/bin'?<br>
</div>/usr/local<br>
<div class="im"><br>
> What should be a common prefix of '/usr/bin/..' and '/usr/bin'?<br>
</div>/usr/bin<br></blockquote><div><br></div><div>seems better than the alternative of interpreting the <font face="courier new, monospace">'..'</font>.</div></div></blockquote><div><br></div>That was the hard choice in the list, my reason for picking this result is that interpreting '..' can change the meaning of a path when dealing with symbolic links and therefore would make the function less useful (and you can always call os.path.normpath when you do want to interpret '..').  </div><div><br></div><div>Stripping '.' elements would be fine, e.g. commonpath('/usr/./bin/ls', '/usr/bin/sh') could be '/usr/bin'. </div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<br>
* Relative paths that don't share a prefix should raise an exception<br></blockquote><div><br></div><div>Why? Why is an empty path not a reasonable result?</div></div></blockquote><div><br></div><div>An empty string is not a valid path.  Now that I reconsider this question: "." would be a valid path, and would have a sane meaning.</div><br><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


* On windows two paths that don't have the same drive should raise an exception<br></blockquote><div><br></div><div>I disagree. On unix systems, should two paths that don't have the same drive also raise an exception? What if I'm using this function on windows to compare two http paths or two paths to a remote unix system? Raising an exception in either case would be wrong.</div></div></blockquote><div><br></div><div>The paths in URLs don't have a drive, hence both URL paths would have the "same" drive.   More importantly: posixpath.commonpath would be better to compare two http or remote unix paths as that function uses the correct separator (ntpath.commonpath uses a backslash as separator)</div><div><br></div><div>Also: when two paths have a different drive letter or UNC share name there is no way to have a value for the prefix that allows for the construction of a path from the common prefix to one of those paths.</div><div><br></div><div>That is,</div><div><br></div><div>     path1 = "c:\windows"</div><div>     path2 = "d:\data"</div><div><br></div><div>     pfx = commonpath(path1, path2)</div><div><br></div><div>The only value of pfx that would result in there being a value of 'sfx' such that   os.path.join(pfx, sfx) == path1 is the empty string, but that value does not refer to a filesystem location.  That means you have to explictly test if commonpath returns the empty string because you likely have to behave differently when there is no shared prefix. I'd then prefer if commonpath raises an exception, because it would be too easy to forget to check for this (especially when developing on a unix based platform and later porting to windows).  An exception would mean code blows up, instead of giving unexpected results (leading to questions like "Why is your program writing junk in my home directory?")</div><div><br></div><blockquote type="cite"><div class="gmail_quote">

<div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<br>
The alternative is to return some arbitrary value (like None) that you have to test for, which would IMHO make it too easy to accidently pass an useless value to some other API and get a confusing exeption later on.<br></blockquote>

<div><br></div><div>Yes, don't return a useless value. An empty string is useful in the relative path case and <font face="courier new, monospace">'/'</font> is useful in the non-relative but paths don't have common prefix at all case. </div></div></blockquote><div><br></div>"/" *is* the common prefix for absolute paths on Unix that don't share any path elements.  As mentioned above "." (or rather os.path.curdir) would be a sane result for relative paths.</div><div><br></div><div>Ronald <br><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div><br></div><div>--- Bruce</div></div>
</blockquote></div><br></body></html>