Class _locale

Unicode. In general, Java and its locale settings are quite unicode heavy, making rich use of different symbols for e.g. currencies. This solution allows some of that to leak through by encoding the Java locale value with the current character encoding. The Python locale module is quite conservative and tends to keep things as solely strings. Python 2.x usually supports only string / ascii by default in many cases, and only unicode when asked. This is a little less conservative while only allowing values consistent with the current encoding.

An example of this is some Python implementations using EUR rather than the Euro symbol € ('u20ac'), probably because € is only available in Unicode. In the Java implementation, if UTF-8 encoding is set, the resulting entry in localeconv()['currency_code'] is '\xe2\x82\xac'. This can be used by print() and related functions directly. Encoding failures for currency_symbol fall back to int_curr_symbol (eg EUR). Encoding failures for negative_sign, which are sometimes unicode, fall back to an ANSI hyphen ('-'). Other encoding failures fallback to the 'C' locale values, where possible.

The C emulation locale uses only ANSI characters in non-unicode strings, in keeping with it being the locale of last resort and maximum compatibility.

Positive sign position (p_sign_posn) is not a distinguished concept in Java and so this is hardcoded to 3.

This class ensures read/write consistency, when changing locales via setlocale(PyInteger,PyString), by declaring private variable currentLocale as volatile, and only assigning it immutable objects. It does not lock to guarantee sequencing of setLocale() calls from separate threads. In the rare cases where that would be needed, it is the responsibility of the calling code.