The attached file, `pep-235-on-posix.export', contains 3 patches; the file includes the intended commit messages and authorship information. To apply these patches, save the file to:

  /path/to/pep-235-on-posix.export

and then run the following from within your Mercurial repository:

  hg import /path/to/pep-235-on-posix.export

I ran `make test' or `./python -m test.regrtest' multiple times, and all but one attempt succeeded: There was a transient and probably unrelated error that occured whilst running `test_thread'.

Only the initial patch alters functionality; the other patches, though structurally useful, are a matter of essentially opportunistic aesthetic reconstruction.

Here is the commit message of the initial patch (the formatting of which may be mangled here):

----8<------8<------8<------8<----

PEP 235: Extend to every POSIX system the case-sensitivity semantics for `import'

(Note: As per PEP 235, this explicit checking of case may be effectively disabled by defining the environment variable `PYTHONCASEOK'.)

From time to time, even a user of a sane system has been known [to be forced] to use an insane file system; the semantics of PEP 235 need to be implemented in this case as well.

On a sane system, mount an insane file system at "$mount", and then run this example:

  $ cd "$mount"
  $ touch Insane.py
  $ python -c 'import Insane; import insane; print(dir())'

Before this revision, the resulting output is:

  ['Insane', '__builtins__', '__doc__', '__name__', '__package__', 'insane']

After this commit, the resulting output is sane:

  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  ImportError: No module named insane

Because POSIX systems may be a subset of sane systems, this is only a partial fix to the overall problem; as much as possible, *every* system should implement the same semantics.

----8<------8<------8<------8<----

The one irritation of this patch is that it arguably adds overhead to "sane" systems, which will almost never run into this corner case.

However, there are at least 4 replies to this criticism:

1) As per PEP 235, the overhead can be virtually removed by setting the `PYTHONCASEOK' environment variable.

2) It's probably most important for Python to present consistent behavior across systems; if one needs every cycle, then one can hack the source for oneself (and if imports are a major bottleneck for some program, then there is probably something seriously wrong with the design of that program, anyway).

3) Ultimately, I can say that while working on a supposedly sane system, I *did* run into this corner case: The program I was trying to run was located on an HFS+ file system; I didn't even know that this program employed Python for one of its components, but it failed with strange, nearly inscrutable errors, which turned out to be the result of the sane system's `python' knowing nothing about PEP 235. Once fixed, that program ran without any problems; the sole pain in the arse was `python'.

4) Come on! Come on, man! Come on; I did a good job here. Come on!

As an aside, I believe that Python 3 is not affected by this problem.