FAQ
I seem to be seeing a new case sensitivity to the import command under
windows (Win98 FAT 32).

import _tkinter

is failing from import Tkinter. If 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

in other words the so-called long file name is all upper case. Now if
in that directory I do a (case sensitive)

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. This is either ActiveState 2.1 binary
or the AS source distribution build with MSVC 5.

I've also had 'import idlever' fail from idle - same thing: it's
a DOS 8.3 file name with no mixed case. No problem with execfile.

I never has this problem under 2.0

Many thanks,

Mike.

Search Discussions

  • Tim Peters at Jun 23, 2001 at 2:28 am
    [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

    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).
  • Mike Clarkson at Jun 24, 2001 at 3:16 am

    On Fri, 22 Jun 2001 22:28:26 -0400, "Tim Peters" 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.
  • Tim Peters at Jun 24, 2001 at 4:31 am
    [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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJun 23, '01 at 1:29a
activeJun 24, '01 at 4:31a
posts4
users2
websitepython.org

2 users in discussion

Tim Peters: 2 posts Mike Clarkson: 2 posts

People

Translate

site design / logo © 2022 Grokbase