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

Sorry, should have gone to the list. On 23 April 2010 01:53, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I don't know if you actually use case insensitive filenames regularly (an odd question that, in "normal life" I'd immediately assume 99.99% of people I meet use Windows, but on this list, I tend to assume most people use Unix/Linux or Mac - sorry if my assumption's mistaken) but personally, as a Windows user, I try to keep filename case the way I want it, but I'd tend to double check if moving files to a case sensitive system. But - and this is the key point here for me - the filenames I *type* at the command line often don't match the case on the filesystem (because I'm too lazy to hit the shift key when I know it doesn't matter, for example) and so my expectations very much are based on filesystem case sensitivity, and what's more, it's what I type that's unreliable. As far as I am concerned, any behaviour that relies on filenames differing only in case being handled differently is wrong on Windows. (Yes, that includes gcc's behaviour). All programs should work case insensitively in all cases when dealing with files. Simple. That's my view as a Windows user. I rationalise it as being based on the case sensitivity of the filesystem, but I'll admit I have no experience with using case sensitive filesystems on Windows (for all practical purposes, they don't exist). I also have limited experience with Unix, and all my Unix experience is in situations where all the filesystems are case sensitive. So arguably, my position is Unix == case sensitive, Windows = case insensitive, and a simple switch on sys.platform would work for me. But desktop Linux systems need to deal with such things as FAT32-formatted USB disks, Samba filesystems, etc. And I have no good intuition on how they should be handled. So I fall back on my original rationalisation, that the filesystem behaviour is what matters. So to summarise: * Case sensitivity behaviour determined by host OS would work for me * But it "feels" wrong * Case sensitive everywhere is completely wrong (as it ignores Windows users' expectations) * Choosing a default based on filesystem behaviour is logical, but hard, and there may be no real requirement for it Also, making the user choose every time (for example, GNU find with its -name and -iname options) is not a helpful or portable approach (e.g., I want find . -name *.sql to find all SQL scripts, regardless of platform). Cross-platform tools with a strong focus on file and filename semantics (for example, DVCSs such as Mercurial) have specialist needs, and probably should always write custom code. But for "quick" scripts, something in the standard library which made doing the "right" thing easy would be a huge help. Paul

On 23 April 2010 12:34, Lie Ryan <lie.1296@gmail.com> wrote:
:-) Good point. Which I guess boils down to saying that if there's no consensus, then nothing should be added to the stdlib (which is a conclusion I'm happy with). Paul.

On 23 April 2010 12:34, Lie Ryan <lie.1296@gmail.com> wrote:
:-) Good point. Which I guess boils down to saying that if there's no consensus, then nothing should be added to the stdlib (which is a conclusion I'm happy with). Paul.
participants (2)
-
Lie Ryan
-
Paul Moore