<div dir="ltr">On 12 April 2013 09:39, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, I've taken a look at the code. Right now lower() is used for two<br>
purposes:<br>
<br>
1. comparisons (__eq__ and __ne__)<br>
2. globbing and matching<br>
<br>
While (1) could be dropped, for (2) I think we want glob("*.py") to find<br>
"SETUP.PY" under Windows. Anything else will probably be surprising to<br>
users of that platform.</blockquote><div><br></div><div style>If glob("*.py") failed to find SETUP.PY on Windows, that would be a usability disaster. Too many tools still exist that mangle filename case for anything else to be acceptable. For an easy example, the standard Windows ssh client, putty, is distributed as PUTTY.EXE. shutil.which('putty') needs to find that file if it's to be of any practical use.</div>
<div style><br></div><div style>For comparisons, I think naive Windows users would expect __eq__ comparisons to work case insensitively, but Windows users with any level of understanding of cross-platform portability issues would be comfortable with the idea that this is risky. Having said that, currently there aren't any "pathname comparisons" as such, just string comparisons which "clearly" need application handling.</div>
<div style><br></div><div style>In all honesty, I don't think that equality comparison for path *objects* (as opposed to "pathnames" as strings) is necessarily even well defined. If someone has two path objects and tries to compare them for equality, my first question would be whether that's really what they want to do... (But case-sensitive comparison, with copious warnings, is probably a reasonable practical compromise).</div>
<div><br></div><div style>Paul</div></div></div></div>