New windows case sensitivity in Python 2.1?

[Tim Peters]

[Mike Clarkson, on
 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.

The correct solution is to point this out to the supplier of whatever it is
you're running that created this thing.  WinZip doesn't change case, the
PythonLabs Windows installer creates _tkinter.pyd with the correct case (and
always has, BTW, ever since there was a installer), and I have no personal
knowledge of a distribution gimmick lame enough to do this to you.

> Needless to say, I think Python should work on Windows no matter
> what archiver is used to unpack or install it.

I'm not sure what that means, but am reading it as "I think Python should
work no matter how badly filename case gets mangled".  But it never did, and
doesn't now either, except when you set PYTHONCASEOK.  2.1 tightened the
rules in the interest of x-platform predictability and portability.

> 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.

In context, that's in the paragraph near the end about the consequences of
"rule #B", which isn't relevant here.  What you're seeing is mentioned
explicitly in the final paragraph:

    The potential damage is here:  #2 (matching on ALLCAPS.PY) is
    proposed to be dropped.  Case-destroying filesystems are a
    vanishing breed, and support for them is ugly.  We're already
    supporting (and will continue to support) PYTHONCASEOK for their
    benefit, but they don't deserve multiple hacks in 2001.

Case-destroying archivers and installers are also a vanishing breed, but I
didn't think that also needed to be said <wink>.

> 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.

Believe it or not, yours is the first complaint about this we've gotten.
Since it's functioning as designed and as documented, it won't be considered
a bug, but you could champion another PEP to add back some kind of Windows
hackery here.  I would not be in favor of such a PEP, but can't predict how
much support it would gather.

> 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;
> ...
> Setting PYTHONCASEOK works, but we can't set it on Windows no matter
> what archiver is used to unpack or install Python.

Why not?  Packages can now rely on PEP 235's rules to work across all Python
platforms, and some will break if you set PYTHONCASEOK, but some will also
break if you just hack the snot out of ALLCAPS.PY.  If you want the latter,
you have to accept that some packages won't work, and I'm not sure that set
isn't identical to the set of packages that fail under PYTHONCASEOK.
PYTHONCASEOK will hurt you only if you install packages on the path that
contain files whose names differ only in case (which is still unusual); or
if you develop code using it and are sloppy about case, then try to port to
any other platform.

braindead-file-installers-shouldn't-be-fixed-by-the-interpreter-ly
    y'rs  - tim