test_issue5604 from test_imp is currently failing on OS X !0.6 (py3k branch), with the following output:

======================================================================
ERROR: test_issue5604 (main.ImportTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 121, in test_issue5604
    file, filename, info = imp.find_module(temp_mod_name)
ImportError: No module named test_imp_helper_ä

I think this has something to do with the platform automatically
using NFD normalization for filenames. Here's an interactive session:

Python 3.2a0 (py3k:78936, Mar 13 2010, 19:42:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, unicodedata
>>> fname = 'test' + b'\xc3\xa4'.decode('utf-8')
>>> with open(fname+'.py', 'w') as file: file.write('a = 1\n')
... 
6
>>> imp.find_module(fname)   # expected this to succeed
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named testä
>>> imp.find_module(unicodedata.normalize('NFD', fname))
(<_io.TextIOWrapper name=4 encoding='utf-8'>, 'testä.py', ('.py', 'U', 1))

In contrast, a simple 'open' doesn't seem to care about normalization:

>>> open(fname+'.py')
<_io.TextIOWrapper name='testä.py' encoding='UTF-8'>
[50305 refs]
>>> open(unicodedata.normalize('NFD', fname)+'.py')
<_io.TextIOWrapper name='testä.py' encoding='UTF-8'>
[50305 refs]

Also affects 3.1.

Brett: any thoughts on this? Should imp.find_module automatically apply NFD normalization to the given string on OS X?

It seems to me that doing this properly is a bit nasty, since the correct condition isn't that the OS is OS X, but that the relevant filesystem is HFS+; presumably a single call to imp.find_module could end up checking directories with differing filesystems.

Trying to get this right is nasty as mixed filesystem stuff is always tricky, especially since NFD is still UTF-8 as is NFC so sys.getdefaultencoding() doesn't help.

Without some way to get that extra bit of info about what form of UTF-8 encoding is being used for the filesystem, I think the test should be modified to use os.listdir() to find the name as encoded by the filesystem and use that as the argument to imp.find_module() instead of assuming the filesystem didn't tweak what it was given.

Test failing on 3.1.2rc1. Should this be considered a release blocker? Perhaps just disable temporarily?

(BTW, the problem exists on other versions of OS X, not just 10.6.)

Note: issue bpo-8180 is related to the same NFC/NFD issue.
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

Could you tell if the patch fix the issue?

That patch works for me.

(You should probably commit the comment fix in the patch separately though, rather than mixing it up with this issue.)

Patch works for me as well. Go ahead and commit it, Florent, with the comment fix as a separate commit as Mark suggested.

Fixed with r79144 on 3.x and r79146 on 3.1.