OpenVMS import (was Re: Windows/Cygwin/MacOSX import (was RE: python-dev summary, 2001-02-01 - 2001-02-15)

zessin at zessin at
Sun Feb 18 17:23:26 CET 2001

Cameron Laird wrote:
>In article <mailman.982310784.27748.python-list at>,
>Tim Peters < at> wrote:
>>[Michael Hudson]
>>> ...
>>>    * Imports on case-insensitive file systems *
>>>  There was quite some discussion about how to handle imports on a
>>>  case-insensitive file system (eg. on Windows).  I didn't follow the
>>>  details, but Tim Peters is on the case (sorry), so I'm confident it
>>>  will get sorted out.
>>You can be sure the whitespace will be consistent, anyway <wink>.
>			.
>			.
>			.
>>them is ugly.  We're already supporting (and will continue to support)
>>PYTHONCASEOK for their benefit, but they don't deserve multiple hacks in
>>Flame at will.
>>or-flame-at-tim-your-choice-ly y'rs  - tim
>1.  Thanks.  Along with all the other benefits, I find
>    this explanation FAR more entertaining than anything
>    network television broadcasts (although nearly as
>    tendentious as "The West Wing").
>2.  I hope a few OS/400 and OpenVMS refugees convert and
>    walk through the door soon.  *That* would make for a
>    nice dose of fun.

Let's see if I can explain the OpenVMS part.
I'll do so by walking over Tim's text. (I'll step carefully over it.
 I don't intend to destroy it, Tim ;-)

] Here's the scoop:  file systems vary across platforms in whether or not they
] preserve the case of filenames, and in whether or not the platform C library
] file-opening functions do or don't insist on case-sensitive matches:
]                        case-preserving   case-destroying
]                     +-------------------+------------------+
]    case-sensitive   | most Unix flavors | brrrrrrrrrr      |
]                     +-------------------+------------------+
]    case-insensitive | Windows           | some unfortunate |
]                     | MacOSX HFS+       | network schemes  |
]                     | Cygwin            |                  |
                      |                   | OpenVMS          |
]                     +-------------------+------------------+

I'm glad we're only 'unfortunate' and not in the 'brrrrrrrrrr' section ;-)

] In the upper left box, if you create "fiLe" it's stored as "fiLe", and only
] open("fiLe") will open it (open("file") will not, nor will the 14 other
] variations on that theme).

] In the lower right box, if you create "fiLe", there's no telling what it's
] stored as-- but most likely as "FILE" --and any of the 16 obvious variations
] on open("FilE") will open it.

>>> f = open ('fiLe', 'w')

$ directory f*



>>> f = open ('filE', 'r')
>>> f
<open file 'filE', mode 'r' at 3E03B8>

This is on the default file system (ODS-2). Only very recent versions of
OpenVMS Alpha (V7.2 and up) support the ODS-5 FS that has Windows-like
behaviour (case-preserving,case-insensitive), but many sites don't use it
(yet). Also, there are many older versions running in the field that don't
get upgraded any time soon.

] The lower left box is a mix:  creating "fiLe" stores "fiLe" in the platform
] directory, but you don't have to match case when opening it; any of the 16
] obvious variations on open("FILe") work.

Same here.

] What's proposed is to change the semantics of Python "import" statements,
] and there *only* in the lower left box.
] Support for MaxOSX HFS+, and for Cygwin, is new in 2.1, so nothing is
] changing there.  What's changing is Windows behavior.  Here are the current
] rules for import on Windows:
] 1. Despite that the filesystem is case-insensitive, Python insists on
]    a case-sensitive match.  But not in the way the upper left box works:
]    if you have two files, and on sys.path, and do
]        import file
]    then if Python finds first, it raises a NameError.  It does
]    *not* go on to find; indeed, it's impossible to import any
]    but the first case-insensitive match on sys.path, and then only if
]    case matches exactly in the first case-insensitive match.

For OpenVMS I have just changed 'import.c':
  MatchFilename() and some code around it is not executed.

] 2. An ugly exception:  if the first case-insensitive match on sys.path
]    is for a file whose name is entirely in upper case (FILE.PY or
]    FILE.PYC or FILE.PYO), then the import silently grabs that, no matter
]    what mixture of case was used in the import statement.  This is
]    apparently to cater to miserable old filesystems that really fit in
]    the lower right box.  But this exception is unique to Windows, for
]    reasons that may or may not exist <frown>.

I guess that is Windows-specific code?
Something to do with 'allcaps8x3()'?

] 3. And another exception:  if the envar PYTHONCASEOK exists, Python
]    silently grabs the first case-insensitive match of any kind.

The check is in 'check_case()', but there is no OpenVMS implementation (yet).

] So these Windows rules are pretty complicated, and neither match the Unix
] rules nor provide semantics natural for the native filesystem.  That makes
] them hard to explain to Unix *or* Windows users.  Nevertheless, they've
] worked fine for years, and in isolation there's no compelling reason to
] change them.

] However, that was before the MacOSX HFS+ and Cygwin ports arrived.  They
] also have case-preserving case-insensitive filesystems, but the people doing
] the ports despised the Windows rules.  Indeed, a patch to make HFS+ act like
] Unix for imports got past a reviewer and into the code base, which
] incidentally made Cygwin also act like Unix (but this met the unbounded
] approval of the Cygwin folks, so they sure didn't complain -- they had
] patches of their own pending to do this, but the reviewer for those balked).
] At a higher level, we want to keep Python consistent, and I in particular
] want Python to do the same thing on *all* platforms with case-preserving
] case-insensitive filesystems.  Guido too, but he's so sick of this argument
] don't ask him to confirm that <0.9 wink>.

What are you thinking about the 'unfortunate / OpenVMS' group ?
Hey, it could be worse, could be 'brrrrrrrrrr'...

] The proposed new semantics for the lower left box:
] A. If the PYTHONCASEOK envar exists, same as before:  silently accept
]    the first case-insensitive match of any kind; raise ImportError if
]    none found.
] B. Else search sys.path for the first case-sensitive match; raise
]    ImportError if none found.
] #B is the same rule as is used on Unix, so this will improve cross-platform
] portability.  That's good.  #B is also the rule the Mac and Cygwin folks
] want (and wanted enough to implement themselves, multiple times, which is a
] powerful argument in PythonLand).  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.  An exceptional Windows import currently blows up with a
] NameError or ImportError, in which latter case it still will, or in which
] former case will continue searching, and either succeed or blow up with an
] ImportError.
] #A is needed to cater to case-destroying filesystems mounted on Windows, and
] *may* also be used by people so enamored of "natural" Windows behavior that
] they're willing to set an envar to get it.  That's their problem <wink>.  I
] don't intend to implement #A for Unix too, but that's just because I'm not
] clear on how I *could* do so efficiently (I'm not going to slow imports
] under Unix just for theoretical purity).
] 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.

Would using unique names be an acceptable workaround?

] Flame at will.
] or-flame-at-tim-your-choice-ly y'rs  - tim

No flame intended. Not at will and not at tim.

>Cameron Laird <claird at>

Uwe Zessin

More information about the Python-list mailing list