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 Dmitry.Jemerov, Ilya.Kulakov, alexander.sturm, barry-scott, karolyi, larryv, lemburg, loewis, ncoghlan, ned.deily, r.david.murray, ronaldoussoren, serhiy.storchaka, tsparber, wolma
Date 2017-01-13.08:48:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <6199a640-7e2b-4f5e-945b-b3c419781abb@egenix.com>
In-reply-to <1484279278.87.0.773654036758.issue18378@psf.upfronthosting.co.za>
Content
On 13.01.2017 04:47, Nick Coghlan wrote:
> Accepting "UTF-8" and interpreting it as functionally equivalent to C.UTF-8 will mean that this setting will at least work as desired on servers that offer C.UTF-8.

I don't think that's within the scope of this patch. "UTF-8" is not
a valid locale setting on Linux and so Python should not allow
passing this through the locale normalization process on Linux.

Please also note that SSH does not forward arbitrary env vars.
Only a select few are forwarded and all others have to be
configured. The locale vars are not among the default ones
(see the ssh man page for details).

Aisde: While looking into this I found that the locale module
aliases C.UTF-8 to en_US.UTF-8. This was added as part of
issue #20076 and originates from the X.org locale.alias file.
Time machine and all that :-)
History
Date User Action Args
2017-01-13 08:48:56lemburgsetrecipients: + lemburg, loewis, barry-scott, ronaldoussoren, ncoghlan, ned.deily, r.david.murray, Dmitry.Jemerov, larryv, serhiy.storchaka, wolma, Ilya.Kulakov, tsparber, karolyi, alexander.sturm
2017-01-13 08:48:56lemburglinkissue18378 messages
2017-01-13 08:48:55lemburgcreate