Thanks Nick.  I think we're pretty much in agreement on the details, and I'm
happy to continue fleshing out the PEP on GH.  Just a few comments here.

On Jan 04, 2017, at 04:31 PM, Nick Coghlan wrote:

>I avoided the term "embedded", as I think it would be confusing when
>locale coercion is disabled for the main Python CLI app.
>
>>  It
>> also feels odd to provide instructions on how to reproduce this in `python`
>> cli from the embedded warning.  
>
>That was a request from some of the Fedora folks, as many of the
>developers encountering this warning are expected to be software
>maintenance engineers that will want to reproduce integration issues
>in a standalone Python runtime.
>
>However, I agree it reads strangely, and its arguably redundant given
>the locale coercion warning when running the main Python CLI app. So
>I'll drop it from the upstream PEP, and if we decide we really want it
>for the Fedora system Python, we can tweak the wording in a downstream
>patch.

I like the sample text in #171.

>If you missed it, I think I need to better highlight in the PEP that
>the library does not, and cannot, coerce the locale to C.UTF-8:
>Py_Initialize runs too late in the startup process for that to work
>they way we would want it to.

Yes, I definitely missed this and I think it's important to emphasize that in
the PEP.

I think it would be worth adding some text/sample code about how embedders can
properly initialize their own applications before they call Py_Initialize().

>But yeah, that's a good idea. Since the runtime initialization warning
>and the CLI locale coercion are technically independent, what do you
>think about adding two flags:
>
>* --with[out]-c-locale-coercion (setting PY_COERCE_C_LOCALE for the
>CLI behaviour)
>* --with[out]-c-locale-warning (setting PY_WARN_ON_C_LOCALE for the
>runtime initialization behaviour)

This work for me *if* there's really clear documentation about the scope of
the effects of these flags, i.e. just as you say above: coercion can only
happen in the `python` cli, while the coercion can't happen (and thus only the
warning can be issued) in the library/embedded case.

>If more people were in the habit of setting sensible locales in their
>Docker base images, I doubt I would be bothered about it for Fedora et
>al either.

Funnily, I ran into a case yesterday where C.UTF-8 *wasn't* set by default on
Debian.  We have a suite of tools for building packages -well, several, but in
this case it's sbuild/schroot- and inside the isolated build environment,
C.ASCII is apparently the default.  I believe there are open bugs about trying
to change this to C.UTF-8 but in any case I was working on a package that
failed to build until I explicitly set the locale to C.UTF-8 in the rules
file, because the upstream test suite implicitly used ASCII to decode some
bytes.

So I think this will be useful even for Debian/Ubuntu although we'll likely
see lots of these warnings in the package build environment.  (Unless, and I
haven't checked, the standard Python build helpers already set C.UTF-8; the
package in question doesn't use the standard Python helpers.)

Cheers,
-Barry

Attachment: pgp1HdVHb7GpY.pgp
Description: OpenPGP digital signature

_______________________________________________
Linux-sig mailing list
Linux-sig@python.org
https://mail.python.org/mailman/listinfo/linux-sig

Reply via email to