Message116047
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). |
|
Date |
User |
Action |
Args |
2010-09-10 21:59:26 | vstinner | set | recipients:
+ vstinner, lemburg, pitrou, eric.araujo, Arfrever |
2010-09-10 21:59:25 | vstinner | set | messageid: <1284155965.76.0.632230831431.issue9632@psf.upfronthosting.co.za> |
2010-09-10 21:59:24 | vstinner | link | issue9632 messages |
2010-09-10 21:59:23 | vstinner | create | |
|