[Python-Dev] New Python Initialization API (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sat Apr 6 22:45:36 EDT 2019
- Previous message (by thread): [Python-Dev] New Python Initialization API
- Next message (by thread): [Python-Dev] New Python Initialization API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 6 Apr 2019 at 02:16, Victor Stinner <vstinner at redhat.com> wrote:
> >
PyPreConfig
fields: > > > > *coerceclocalewarn
: if non-zero, emit a warning if the C locale > > is coerced. > > *coerceclocale
: if equals to 2, coerce the C locale; if equals to > > 1, read the LCCTYPE to decide if it should be coerced. > > Can we use another value for coerceclocale to determine whether to > warn or not? Save a field.coerceclocale 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.
Yeah, that's how they ended up being two different fields in the first place. However, I wonder if the two fields might be better named:
- warn_on_legacy_c_locale
- coerce_legacy_c_locale
Neither set: legacy C locale is left alone Only warning flag set: complain about the legacy C locale on stderr Only coercion flag set: silently attempt to coerce the legacy C locale to a UTF-8 based one Both flags set: attempt the coercion, and then complain about it on stderr (regardless of whether the coercion succeeded or not)
The original PEP 580 implementation tried to keep the config API simpler by always complaining, but that turned out to break the world (plenty of contexts where things get upset by unexpected output on stderr).
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] New Python Initialization API
- Next message (by thread): [Python-Dev] New Python Initialization API
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]