homepage

> I'd like to see this patch reverted.
I created a specific branch to test the patch (I also patched PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()): issue10209. test_pep277 now pass in this branch!
> encoding with NFD should not be necessary, as the system will 
> do that, anyway.
Yes, but not exactly... Mac OS X NFD normalization is a little bit different than Python's normalization: see msg105669 and
http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html
I don't understand why test_pep277 pass on issue10209 branch, but it works. I suppose that normalize the filename to NFD in Python avoids some Mac OS X normalization bugs?
> decoding with NFC is incompatible with previous Python releases,
> I can't see why NFC is conceptually better than NFD.
I propose to normalize to NFC because Qt does that.
On Linux, the keyboard uses NFC. Eg. press é key writes U+00e9, not U+0065 U+0301. If you ask the user to write a filename, the filename will be stored in the same norm. So indirectly, Linux stores filenames as NFC.
Which norm is used on Mac OS X, eg. for the keyboard?
To display a filename, the norm is not important. With my patch, the norm is also no more important when accessing to the filesystem (no more strange Mac OS X normalization bug). So it's only important when comparing two filenames. If the two filenames are normalized in different norms (eg. NFC vs NFD), they will be seen as different even if they are the same name.
--
Anyway, I think that os.fsencode(os.fsdecode(name)) should be equal to name. If it's different, "open(name, 'w').close(); name in listdir()" is False (on systems storing filenames as bytes). So if you change fsdecode(), fsencode() should also be changed.