PEP 235, Import on Case-Insensitive Platforms, Peters

pep-0000.txt

@@ -80,6 +80,7 @@ Index by Category
  SF  221  pep-0221.txt  Import As                              Wouters
  SF  223  pep-0223.txt  Change the Meaning of \x Escapes       Peters
  SF  230  pep-0230.txt  Warning Framework                      van Rossum
+ S   235  pep-0235.txt  Import on Case-Insensitive Platforms   Peters
 
  Rejected PEPs
 
@@ -136,6 +137,7 @@ Numerical Index
  S   232  pep-0232.txt  Function Attributes                    Warsaw
  S   233  pep-0233.txt  Python Online Help                     Prescod
  S   234  pep-0234.txt  Iterators                              Yee
+ S   235  pep-0235.txt  Import on Case-Insensitive Platforms   Peters
 
 Key
 

pep-0235.txt

@@ -0,0 +1,151 @@
+PEP: 235
+Title: Import on Case-Insensitive Platforms
+Version: $Revision$
+Author: Tim Peters <tim@digicool.com>
+Python-Version: 2.1
+Status: Draft
+Type: Standards Track
+Post-History: 16 February 2001
+
+
+Note
+
+    This is essentially a retroactive PEP: the issue came up too late
+    in the 2.1 release process to solicit wide opinion before deciding
+    what to do, and can't be put off until 2.2 without also delaying
+    the Cygwin and MacOS X ports.
+
+
+Motivation
+
+    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          |
+                     +-------------------+------------------+
+
+    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.
+
+    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.
+
+    NONE OF THAT IS CHANGING!  Python will continue to follow platform
+    conventions w.r.t. whether case is preserved when creating a file,
+    and w.r.t. whether open() requires a case-sensitive match.  In
+    practice, you should always code as if matches were
+    case-sensitive, else your program won't be portable.
+
+    What's proposed is to change the semantics of Python "import"
+    statements, and there *only* in the lower left box.
+
+
+Current Lower-Left Semantics
+
+    Support for MacOSX 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.
+
+    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.
+
+    3. And another exception: if the environment variable PYTHONCASEOK
+       exists, Python silently grabs the first case-insensitive match
+       of any kind.
+
+    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, by following
+    the same rules on *all* platforms with case-preserving
+    case-insensitive filesystems.
+
+
+Proposed Semantics
+
+    The proposed new semantics for the lower left box:
+
+    A. If the PYTHONCASEOK environment variable 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 environment variable to
+    get it.  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.
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End: