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 lemburg
Recipients Jan Niklas Hasse, abarry, ezio.melotti, lemburg, methane, ncoghlan, r.david.murray, vstinner, yan12125
Date 2016-12-17.10:15:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <7bfd1a2b-a916-1b5f-c8f2-78c462fe84cf@egenix.com>
In-reply-to <1481961380.58.0.954586765946.issue28180@psf.upfronthosting.co.za>
Content
On 17.12.2016 08:56, Nick Coghlan wrote:
> 
> Making an explicit note of this so I remember to mention it in the draft PEP: one of the biggest problems that arises in any attempt at a Python-only solution to overriding the locale is that we can end up disagreeing with C/C++ extensions, and this is *especially* a problem when sharing a process with GUI frameworks like Tcl/Tk, Qt, and GTK (since they tend to read the process-wide settings, rather than querying anything that CPython configures during normal operation).

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.
History
Date User Action Args
2016-12-17 10:15:25lemburgsetrecipients: + lemburg, ncoghlan, vstinner, ezio.melotti, r.david.murray, methane, yan12125, abarry, Jan Niklas Hasse
2016-12-17 10:15:25lemburglinkissue28180 messages
2016-12-17 10:15:25lemburgcreate