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).