This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Jan Niklas Hasse, abarry, ezio.melotti, lemburg, methane, ncoghlan, r.david.murray, vstinner, yan12125
Date 2016-12-17.15:33:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7dS7dMQpeAuVfLmwFym232RXbwEHDayA88=JP7m-1v4BA@mail.gmail.com>
In-reply-to <7bfd1a2b-a916-1b5f-c8f2-78c462fe84cf@egenix.com>
Content
On 17 December 2016 at 20:15, Marc-Andre Lemburg <report@bugs.python.org>
wrote:

> Another use case to consider is embedding the Python
> interpreter in another application. In such situations,
> the C locale will usually already be set by the main
> application and it may conflict with the LANG or other
> locale env var settings, since the user may have chosen
> to use a different locale in the context of the application.
>

Aye, that's the origin of the split proposal to only emit a warning in the
shared library (since CPython might only be a piece of a larger
application), but implement actual locale coercion (by overriding LANG and
LC_ALL in the process environment) in the command line app's main()
function (as in that case we know CPython *is* the application).

The hard part of writing the PEP isn't really going to be explaining the
proposal itself (I expect it to be around a 20 line patch to the C code) -
it's going to be explaining why all the other possibilities we've
considered over the years don't work, and why we (as in the Fedora Python
SIG) think this one actually stands a chance of working properly :)
History
Date User Action Args
2016-12-17 15:33:17ncoghlansetrecipients: + ncoghlan, lemburg, vstinner, ezio.melotti, r.david.murray, methane, yan12125, abarry, Jan Niklas Hasse
2016-12-17 15:33:17ncoghlanlinkissue28180 messages
2016-12-17 15:33:17ncoghlancreate