STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> 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.

Yes, it would be a new function. I was under the impression that
you wanted to use this approach to resolve the problem of not being
able to set the encoding before any file objects get opened in
Python.

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

That's more likely due to the fact that no one is embedding
Python 3.x into their apps yet...

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

That's not the point: the applications will have their own way
of configuring themselves and in GUI apps you most likely do not
use environment variable to setup your application. As a result,
the application has to tell the embedded Python how it was configured
in a way that overrides Python's encoding finding magic.

With your patch, the only way to do this is by having the embedded
application change the OS environment. That's not exactly a very
Pythonic way of doing interfacing.

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

Since you are removing a function that has been around since 3.0,
please make sure that you add proper warnings to 3.1.