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 Arfrever, ezio.melotti, georg.brandl, lemburg, loewis, ned.deily, pitrou, r.david.murray, vstinner
Date 2011-01-28.09:27:53
SpamBayes Score 9.963903e-08
Marked as misclassified No
Message-id <1296206874.76.0.903442834495.issue6203@psf.upfronthosting.co.za>
In-reply-to
Content
Python can be embedded into other applications and unconditionally
changing the locale (esp. the LC_CTYPE) is not good practice, since
it's not thread-safe and affects the entire process. An application
may have set LC_CTYPE (or the locale) to something completely
different.

If at all, Python should be more careful using this call (pseudo
code):

lc_ctype = setlocale(LC_CTYPE, NULL);
if (lc_ctype == NULL || strcmp(lc_ctype, "") || strcmp(lc_ctype, "C")) {
    env_lc_ctype = setlocale(LC_CTYPE, "");
    setlocale(LC_CTYPE, lc_ctype);
    lc_ctype = env_lc_ctype;
}

Then use lc_ctype to figure out encodings, etc.

While this is not thread-safe, it at least reverts the change back
to the original setting and only applies the change if needed. That's
still not optimal, but better than nothing.

An clean alternative would be adding LC_* variable parsing code to
Python to avoid the setlocale() call altogether.
History
Date User Action Args
2011-01-28 09:27:54lemburgsetrecipients: + lemburg, loewis, georg.brandl, pitrou, vstinner, ned.deily, ezio.melotti, Arfrever, r.david.murray
2011-01-28 09:27:54lemburgsetmessageid: <1296206874.76.0.903442834495.issue6203@psf.upfronthosting.co.za>
2011-01-28 09:27:54lemburglinkissue6203 messages
2011-01-28 09:27:53lemburgcreate