We'd still need to support other OSes as well, though, and I don't think that putting all this code into fileobject.c is a good idea -- after all opening files is needed by some other parts of Python as well and may also be useful for extensions.
The stuff isn't in fileobject.c. Py_FileSystemDefaultEncoding is defined in bltinmodule.c. Also, on other OSes: You can pass Unicode object to open on all systems. If Py_FileSystemDefaultEncoding is NULL, it will fall back to site.encoding. Of course, if the system has an open function that expects wchar_t*, we might want to use that instead of going through a codec. Off hand, Win32 seems to be the only system where this might work, and even there, it won't work on Win95.
I'd suggest to implement something similiar to the DLL loading code which is also implemented as subsystem in Python.
I'd say this is over-designed. It is not that there are ten alternative approaches to doing encodings in file names, and we only support two of them, but it is rather that there are only two, and we support all three of them :-) Also, it is more difficult than threads: for threads, there is a fixed set of API features that need to be represented. Doing Py_UNICODE* opening alone is easy, but look at the number of posixmodule functions that all expect file names of some sort. Regards, Martin