GraalPy and CPython show different database entries for same locale

[skirpichev]

I'm certainly not an expert on the locale module, but this seems odd, especially on the same system.

Example:

Python 3.13.5 (tags/v3.13.5:6cb20a219a, Jun 27 2025, 19:37:25) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'ru_RU.UTF-8')
'ru_RU.UTF-8'
>>> locale.localeconv()['thousands_sep']
'\u202f'

vs

Python 3.11.7 (Wed Apr 02 19:57:13 UTC 2025)
[Graal, Oracle GraalVM, Java 24.0.1 (amd64)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'ru_RU.UTF-8')
'ru_RU.UTF-8'
>>> locale.localeconv()['thousands_sep']
'\xa0'

[skirpichev]

BTW, GraalPy also does not follow to locale settings for string formatting:

Python 3.11.7 (Wed Apr 02 19:57:13 UTC 2025)
[Graal, Oracle GraalVM, Java 24.0.1 (amd64)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_NUMERIC, "ps_AF.UTF-8")
'ps_AF.UTF-8'
>>> locale.localeconv()['thousands_sep']
'٬'
>>> s = _
>>> format(123456789, 'n') == f"123{s}456{s}789"
False
>>> format(123456789, 'n')
'123,456,789'

[msimacek]

Thank you for the report. The second issue is easy to fix, I'll do it soon. The first issue is because we use the Java locale objects and it seems the JVM has different definitions for those. Is it something that has changed recently in the unicode standard? We could consider switching to ICU4J for locale handling (we already use it for string conversions) since that should have up-to-date unicode support, but it would take some time to implement.

[skirpichev]

The second issue is easy to fix, I'll do it soon.

Thanks. That at least provide some way to workaround implementation differences e.g. in tests.

Is it something that has changed recently in the unicode standard?

Not, as far as I know.