$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import normcase
>>> normcase ('aB')
'aB'
>>>

From http://docs.python.org/lib/module-os.path.html: "On Unix, this
returns the path unchanged; on case-insensitive filesystems, it converts
the path to lowercase." Of course, Mac OS X is both Unix and
case-insensitive, which is a rather bizarre combination, but that's it
is. Where is the item for "make all file systems case-sensitive, put
the case-insensitivity in the user interface"?

"Of course, Mac OS X is both Unix and case-insensitive"

Not so. Case-{in|}sensitivity is an attribute of HFS+ file systems that is
specifiable when a file system is created; it's true that the default is
still case-insensitive. There are also other case-sensitive file systems
supported on OS X.

Ok, good point. Perhaps the documentation should be updated to clarify
that Mac OS is treated as Unix even though a default Mac OS X
installation will have a case-insensitive file system. Wouldn't it be
possible for a Windows machine to have a case-sensitive file system
similarly? Or is it more "built-in" that the file system on a Windows
box will be case-insensitive?

On Windows, case-insensitivity is part of the API, not of the file
system. NTFS itself is case-sensitive, and there are case-sensitive
subsystems on top of it (e.g. the POSIX subsystem, Interix). Win32, when
calling the file system, asks for case-insensitive lookup (which NTFS
also supports efficiently).

I believe FAT is inherently case-insensitive.

The following patch explicitly mentions that os.path.normcase treats OSX
like any other Unix platform.

I'm in favor of applying this.

I've committed a fix for this in r70746 and ported this to 3.1 and 2.6 as
well.

I'm reopening this because now the normcase implementation of posixpath has a todo that says "on Mac OS X, this should really return s.lower()." (see r66743).
There is some discussion about this in bpo-9018.

The comment is wrong, os.path.normcase should not return s.lower(), as the other issue notes the case sensitivity is filesystem dependent.

Returning s.lower() will break code when dealing with paths that refer to an NFS share on a Linux server, or to a path on a local case sensitive file system.

IMHO The comment in posixpath should be changed to something like this:

# On MacOS X most but not all filesystems are case sensitive, which
# means that using normcase(p1) != normcase(p2) doesn't necessarily mean
# that the paths refer to different files.

The current comment gives the impression that a trivial should be applied, which isn't true.

Changing the function is better than changing the comment.
Although changing just the comment is better than leaving it unchanged.

Note that this does not just affect MacOSX, this even affects Linux (although the behaviour on the default filesystems is different).

On Linux the default is case-sensitive filesystems, but you can use network filesystems that have case-insensitive behavior, for example by using a CIFS share.

This means that /mnt/myserver-share/foo/bar and /mnt/myserver-share/FOO/BAR may or may not refer to the same "object": there aren't the same if /mnt/myserver-share is a regular Linux filesystem but will be when /mnt/myserver-share is a mount from a CIFS server.

In short: os.path.normcase is hopelessly naive in its assumptions about system behavior.

Is this or could this be addressed via the new pathlib module?

New changeset a854d23305de by Ned Deily in branch '3.4':
Issue bpo-3485: remove misleading comment
http://hg.python.org/cpython/rev/a854d23305de

New changeset 3edda677119e by Ned Deily in branch 'default':
Issue bpo-3485: merge from 3.4
http://hg.python.org/cpython/rev/3edda677119e

The misleading "TODO" comment has been removed.