homepage

I didn't proposed to add a new parameter to Py_InitializeEx() (which means create a new function to not break the API), I just wrote that _Py_SetFileSystemEncoding() doesn't work for your use case.
> If you embed Python into another application, say as scripting
> language for that application, that other application may have
> completely different requirements for the user setup than Python
> expects, e.g. for a Windows GUI application it's not feasible to
> ask the user to change the environment variables via the registry
> in order for Python to pick up the right encoding information.
Is this usecase really realistic? Except you, nobody asked for this feature.
> The application will likely have its own way
> of configuring things like file system or I/O stream encodings.
> Think of e.g. GTK or Qt applications as example.
Qt uses the unicode API on Windows: nativeOpen() uses CreateFile() (in wide chararacter mode), see src/corelib/io/qfsengine_win.cpp.
Gtk+ (glib) uses also the unicode API on Windows: g_fopen() uses _wfopen(), see glib/gstdio.c.
Python3 doesn't support your usecase currently (it doesn't work). If you consider it important, please open a new issue.
--
I commited my patch to 3.2 (r84687).