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
pgp1HdVHb7GpY.pgp
Description: OpenPGP digital signature
_______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
