New windows case sensitivity in Python 2.1?
Mike Clarkson
support at internetdiscovery.com
Sat Jun 23 23:16:36 EDT 2001
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.
More information about the Python-list
mailing list