git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] New Python Initialization API


On Sat, 6 Apr 2019 at 02:16, Victor Stinner <vstinner at 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.

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