Marc-Andre Lemburg <m...@egenix.com> added the comment: STINNER Victor wrote: > > STINNER Victor <victor.stin...@haypocalc.com> added the comment: > > "keep the C function" > > Hum, currently, Python3 only has a *private* function called > _Py_SetFileSystemEncoding() which can only be called after _Py_InitializeEx() > (because it relies on the codecs API). If you consider that there is a real > use case, we should create a function to set the filesystem encoding, > function that should (have to?) be called before Py_InitializeEx(). > > I still think that Python knows better than the application how to set the > encoding (when, how to choose it, etc.).
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. What we'd need is a way for the embedding application to provide this information in a way that doesn't require setting up the environment in some special way. 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. The Py_InitializeEx() function sounds like a good idea to pass the information about such important extra parameters to Python. This could take arguments for setting the file system encoding as well as the I/O encoding. The arguments would then override the env var settings. So you can remove the function, but have to keep a backdoor open for use cases like the one I described above. The Py_InitializeEx() function approach would also avoid all the issues that you have with calling _Py_SetFileSystemEncoding() after the interpreter has been initialized. ---------- _______________________________________ 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
