Message283495
| 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 :) |
|