Maybe I should clarify in the PEP 587 Rationale what are the use cases for the API. Embeding Python is one kind of use case, but writing your own Python with a specific config like "isolated Python" or "system Python" is also a valid use case. For a custom Python, you might want to get C locale coercion and UTF-8 Mode. The most common case is to embed Python in an application like Blender or vim: the application already executes a lot of code and manipulated strings and encoding before Python is initialized, so Python must not coerce the C locale in that case. That's why Nick and me decided to disable C loclae coercion and UTF-8 Mode by default when the C API is used. Victor Le samedi 6 avril 2019, Inada Naoki <songofacandy@gmail.com> a écrit :
On Sat, Apr 6, 2019 at 1:13 AM Victor Stinner <vstinner@redhat.com> wrote:
``PyPreConfig`` fields:
* ``coerce_c_locale_warn``: if non-zero, emit a warning if the C
locale
is coerced. * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to 1, read the LC_CTYPE to decide if it should be coerced.
Can we use another value for coerce_c_locale to determine whether to warn or not? Save a field.
coerce_c_locale is already complex, it can have 4 values: -1, 0, 1 and 2. I prefer keep a separated field.
Moreover, I understood that you might want to coerce the C locale *and* get the warning, or get the warning but *not* coerce the locale.
Are these configurations are really needed?
Applications embedding Python may not initialize Python interpreter at first. For example, vim initializes Python when Python is used first time.
On the other hand, C locale coercion should be done ASAP application starts.
I think dedicated API for coercing C locale is better than preconfig.
// When application starts: Py_CoerceCLocale(warn=0);
// later... Py_Initialize();
-- Inada Naoki <songofacandy@gmail.com>
-- Night gathers, and now my watch begins. It shall not end until my death.