[Python-ideas] Small enhancement to os.path.splitext

[Paul Moore]

On 21 April 2010 11:58, Fred Drake <fdrake at acm.org> wrote:
> As such legacy fades (however slowly), should we *increase* the amount
> of code that deals with it, or should we move on?

It's not clear to me that it's all "legacy". I had the impression that
MacOS used a case insensitive filesystem - is that right? Certainly, I
know that MacOS uses Unicode normalisation, so simple string
comparison is definitely not correct. (I only use MacOS as an example
to avoid the assumption that this is a Windows-only issue - there are
also case-insensitive filesystems available for Unix in general, if
nothing else SMBFS).

Certainly, non-case-preserving systems are a dying breed. But from
what I've read, the situation around case sensitivity is far less
clear - I've even seen comments from Unix users that claim they would
like Unix to move away from case sensitivity. (I'm not qualified to
judge the relevance or importance of such claims, I merely note that
they exist).

Like it or not, treating filenames as uninterpreted byte strings will
violate some users' expectations. Library support for dealing with
user expectations at a higher level would be good.

Unfortunately, from my reading, it seems like at least on Linux,
filesystem writers are expected to implement their own path handling
(at least, that's how I interpret the FUSE documentation, and I
couldn't find any lower level filesystem driver documentation that
implied otherwise). So, at the filesystem level, it seems that on
Linux all bets are off - I could, in theory, write a filesystem that
was case insensitive for consonants, but case sensitive for vowels.
And stored filenames in bit-reversed UTF-8. Bleh.

Paul.