On Fri, Sep 24, 2010 at 5:17 AM, R. David Murray <rdmur...@bitdance.com> wrote:
> On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers <ch...@simplistix.co.uk>
> wrote:
>> On 18/09/2010 23:36, Guido van Rossum wrote:
>> > course, exists() and isdir() etc. do, and so does realpath(), but the
>> > pure parsing functions don't.
>>
>> Yes, but:
>>
>> H:\>echo foo > TeSt.txt
>> ...>>> import os.path
>> >>> os.path.realpath('test.txt')
>> 'H:\\test.txt'
>> >>> os.path.normcase('TeSt.txt')
>> 'test.txt'
>>
>> Both feel unsatisfying to me :-S
>>
>> How can I get 'TeSt.txt' from 'test.txt' (which feels like the contract
>> normcase *should* have...)
>
> You can't, and you shouldn't be able to. "normalization" is something
> that happens without reference to existing objects, the whole point
> is to put the thing into "standard form" so that you can compare
> strings obtained from different sources and know that they will
> represent the same object on that filesystem.
Clearly there is another use case where people want to display the
filename back to the user with the correct case. This is a reasonable
request and I think it makes sense for us to add another API to
os.path that does this by looking up the path on the filesystem, or
making an OS-specific call.
>> > They can be used without a working
>> > filesystem even. (E.g. you can import ntpath on a Unix box and happily
>> > parse Windows paths.)
>>
>> But what value does that add over just doing a .lower() on the path?
>
> It does what is appropriate for that....oh, yeah. For that OS, not
> "for that filesystem". (e.g. on Unix normcase does nothing since files
> with different cases but the same letters are different files.)
Yeah, which is wrong on Mac OS X -- that's Unix but the default
filesystem is case-preserving (though apparently it's possible to
mount case-sensitive filesystems too). I've heard that on Windows
there are also case-sensitive filesystems (part of a POSIX compliance
package?). And on Linux you can mount FAT32 filesystems which are
case-preserving.
> Being os specific rather than file system type specific is the usability bug.
Agreed.
> But to fix it we'll need to introduce a 'filesystems' module enumerating
> the different file systems we support, with tools for figuring out
> what filesystem your program is talking to. But normacase still,
> wouldn't (shouldn't) do what you want.
I don't think we should try to reimplement what the filesystem does. I
think we should just ask the filesystem (how exactly I haven't figured
out yet but I expect it will be more OS-specific than
filesystem-specific). It will have to be a new API -- normcase() at
least is *intended* to return a case-flattened name on OSes where
case-preserving filesystems are the default, and changing it to look
at the filesystem would break too much code. For a new use case we
need a new API.
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
