<div><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><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><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><br></div><div><div>It would also be a bit surprising that there are cases where commonpath(a,a) != a.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<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> </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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><br></div><div><br></div><div>--- Bruce</div></div>