New windows case sensitivity in Python 2.1?

[Mike Clarkson]

On Fri, 22 Jun 2001 22:28:26 -0400, "Tim Peters" <tim.one at home.com>
wrote:

>[Mike Clarkson]
>> I seem to be seeing a new case sensitivity to the import command under
>> windows (Win98 FAT 32). ...
>
>Yes, this was the topic of PEP 235 (Import on Case-Insensitive Platforms),
>implemented for Python 2.1.  See
>
>    http://python.sourceforge.net/peps/pep-0235.html

Thanks Tim, but I think what I'm seeing is not what PEP 235 intended,
or there is an imprecision in the PEP that needs elucidating.

In my example of trying to 'import _tkinter' failing, when I open a
DOS command window, and change to the Dll's directory, a DIR shows me

_TKINTER PYD        22,528  06-13-01 10:53p _TKINTER.PYD

Now the thing that decided _tkinter.pyd should be stored as 
_TKINTER.PYD was the M$ installer that put the file there (AS binary),
or my WinZip and/or tar in the case of a source distribution.
Needless to say, I think Python should work on Windows no matter
what archiver is used to unpack or install it.

The PEP wanted: it
    can't cause any existing non-exceptional Windows import to fail,
    because any existing non-exceptional Windows import finds a
    case-sensitive match first in the path -- and it still will.  

but it's now failing because the so-called long file name is all upper
case, due to the archiver/installer. I think for a 'non-exceptional
Windows import' the comparison to 8.3 compliant targets (_tkinter.pyd)
must be first case-INsensitive match, no matter what  PYTHONCASEOK is.

When I do a (case sensitive) DOS command in the Dll's directory:

rename _tkinter.pyd foo
rename foo _tkinter.pyd

DIR shows me

_TKINTER PYD        22,528  06-13-01 10:53p _tkinter.pyd

and the import works, so the import is matching against the long
filename; i.e.  "if long_filename == short_filename", can't be used
as a test of 8.3 names. I think for DOS 8.3 file names with no mixed
case on Windows VFAT, case itself is undefined, which is why different
installers/archivers give different results (not to mention NTFS :-<).

>for the full story.  If for some reason you can't, or don't want to, use
>matching case, you'll have to set the envar PYTHONCASEOK (to anything --
>just so long as it's defined).

Setting PYTHONCASEOK works, but we can't set it on Windows no matter
what archiver is used to unpack or install Python.  Set
PYTHONCASENOTOK instead :-)? The ugly exception gets uglier. 

Many thanks,

Mike.