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 ncoghlan, ned.deily
Date 2018-11-06.11:07:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1541502448.95.0.788709270274.issue34589@psf.upfronthosting.co.za>
In-reply-to
Content
The discussion with Victor on https://bugs.python.org/issue34914 highlighted the fact that it's OK to use 8-bit string comparisons to check for "-E", "-I", and a "-X coerce_legacy_c_locale=0" due to the fact that all encodings used as locale encodings are sufficiently ASCII compatible for that to work as desired.

So before proceeding with merging https://github.com/python/cpython/pull/9257, I'm going to review that possibility, and see how much code it would actually add to support an extra internal helper API like:

    int _Py_LegacyLocaleCoercionEnabled(int argv, char* argv[]);

That would then inspect the unprocessed 8-bit command line arguments, as well as the process environment, to determine whether or not locale coercion should be attempted, making the complete dance:

    _Py_SetLocaleFromEnv(LC_CTYPE);
    if (_Py_LegacyLocaleDetected() && _Py_LegacyLocaleCoercionEnabled(argc, argv))
    {
        _Py_CoerceLegacyLocale(&pymain.report_locale_coercion);
    }

If we wanted to officially expose this for embedding apps, the API would need a bit more thought, so it probably makes sense to wait and see if the nominally-private-but-exposed-to-the-linker approach is good enough in practice.
History
Date User Action Args
2018-11-06 11:07:29ncoghlansetrecipients: + ncoghlan, ned.deily
2018-11-06 11:07:28ncoghlansetmessageid: <1541502448.95.0.788709270274.issue34589@psf.upfronthosting.co.za>
2018-11-06 11:07:28ncoghlanlinkissue34589 messages
2018-11-06 11:07:28ncoghlancreate