Marc-Andre Lemburg <m...@egenix.com> added the comment: STINNER Victor wrote: > > STINNER Victor <victor.stin...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9632> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com