OpenVMS import (was Re: Windows/Cygwin/MacOSX import (was RE: python-dev summary, 2001-02-01 - 2001-02-15)
zessin at decus.de
zessin at decus.de
Sun Feb 18 11:23:26 EST 2001
Cameron Laird wrote:
>In article <mailman.982310784.27748.python-list at python.org>,
>Tim Peters <tim.one at home.com> 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
>>2001.
>>
>>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 |
] +-------------------+------------------+
Phew.
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*
Directory DSA3:[PYTHON.PYTHON-2_1A2CVS.VMS]
FILE.;1
>>> 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, FiLe.py and file.py on sys.path, and do
]
] import file
]
] then if Python finds FiLe.py first, it raises a NameError. It does
] *not* go on to find file.py; 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 NeoSoft.com>
>Business: http://www.Phaseit.net
>Personal: http://starbase.neosoft.com/~claird/home.html
--
Uwe Zessin
More information about the Python-list
mailing list