> > I noticed that these days __file__ attributes of modules are case > > normalized (ie. lowercased on case insensitive file systems), or > > at least the directory part. Then I noticed that this is caused by > > the fact that all sys.path entries are case normalized. It turns > > out that site.py does this, in a function called makepath(), added > > by Fred about 8 months ago. > > > > I think this is wrong: we should always try to *preserve* case. > > There is an added problem with the makepath() stuff that I hadn't > reported here yet: it has broken MacPython on some non-western > machines. Specifically I've had reports of people running a Japanese > MacOS that things will break if they run Python from a pathname that > has any non-7-bit-ascii characters in the name. Apparently normcase > normalizes more than just ascii upper/lowercase letters. > > And aside from that I fully agree with Just: seeing a stacktrace > with all lowercase filenames is _very_ disconcerting. > > I would disable the case-normalization for MacPython, except that I > don't know whether it actually has a function. With MacPython's way > of finding the initial sys.path contents we don't have the > Windows-Python problem that we add the same directory 5 times (once > in uppercase, once in lowercase, once in mixed case, once in > mixed-case with / for \, etc:-), so if this is what it's trying to > solve we can take it out easily. I can't think of any function besides the attempt to avoid duplicates. I think that even on Windows, retaining case makes sense. I think that there's a way to avoid duplicates without case-folding everything. (E.g. use a case-folding comparison instead.) I wonder if maybe path entries should be normpath'd though? I'll leave it to Fred, Jack or Just to fix this. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4