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.
> 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). ---------- resolution: -> fixed status: open -> closed _______________________________________ 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
