On 2/20/06, <b class="gmail_sendername">Mark Mc Mahon</b> &lt;<a href="mailto:mark.m.mcmahon@gmail.com">mark.m.mcmahon@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It seems that the Path module as currently defined leaves equality<br>testing up to the underlying string comparison. My guess is that this<br>is fine for Unix (maybe not even) but it is a bit lacking for Windows.<br><br>
Should the path class implement an __eq__ method that might do some of<br>the following things:<br> - Get the absolute path of both self and the other path<br> - normcase both<br> - now see if they are equal<br></blockquote>
</div><br>This has been suggested to me many times.<br><br>Unfortunately, since Path is a subclass of string, this breaks stuff in weird ways.<br><br>For example:<br>&nbsp;&nbsp;&nbsp; 'x.py' == path('x.py') == path('X.PY') == 'X.PY', but '
x.py' != 'X.PY'<br><br>And hashing needs to be consistent with __eq__:<br>&nbsp;&nbsp;&nbsp; hash('x.py') == hash(path('X.PY')) == hash('X.PY') ???<br><br>Granted these problems would only pop up in code where people are mixing Path and string objects.&nbsp; But they would cause really obscure bugs in practice, very difficult for a non-expert to figure out and fix.&nbsp; It's safer for Paths to behave just like strings.
<br><br>-j<br><br>