-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
locale.nl_langinfo(locale.ALT_DIGITS) does not work #124969
Comments
Now it returns a tuple of up to 100 strings (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string.
Now it returns a tuple of up to 100 strings (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string.
@freakboy3742: this fix broke the iOS buildbot. You might have opinions on how to handle this on non-glibc platforms :) |
…124974) Now it returns a tuple of up to 100 strings (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string.
It is interesting that ALT_DIGITS is a FreeBSD extension. And was inherited on Apple platforms. I wonder whether it is not set only for Japanese or for other locales (not installed on buildbots) too? fa_IR, lzh_TW, my_MM, or_IN, shn_MM? |
Skip the locale.ALT_DIGITS test on all Apple platforms, not just macOS.
@serhiy-storchaka AFAICT, |
…thonGH-124974) Now it returns a tuple of up to 100 strings (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string. (cherry picked from commit 21c04e1) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
…thonGH-124974) Now it returns a tuple of up to 100 strings (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string. (cherry picked from commit 21c04e1) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
…thonGH-124974) (pythonGH-125232) (cherry picked from commit 26a9318) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Returns a tuple of up to 100 strings for ALT_DIGITS lookup (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string. (cherry picked from commit 21c04e1)
…H-124974) (GH-125232) (GH-125284) (cherry picked from commit 26a9318) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Returns a tuple of up to 100 strings for ALT_DIGITS lookup (an empty tuple on most locales). Previously it returned the first item of that tuple or an empty string. (cherry picked from commit 21c04e1) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Now it could be used in the |
The 3.12 buildbot now fails: https://buildbot.python.org/#/builders/1185/builds/971 |
Fixed by #125311. |
Hi, correct me if I am wrong, but I don't think that As it's implemented now, it's very Linux specific. On Solaris, the newly added test is failing for two reasons:
On FreeBSD, I didn't find any locale that had alt_digits defined (so the tests will likely fail as well?), but I don't know about the format it returns. I can look into the semicolon separated string parsing for platforms where that is the case. |
Thank you for pointing on this @kulikjak. It was used in Python sources as optionally defined, and it was not even documented in Linux manpages, so I thought that it is a unofficial extension. Does it mean that import locale, subprocess
alllocales = subprocess.check_output(['locale', '-a']).decode().split()
for loc in alllocales:
if '.' in loc or '@' in loc:
continue
try:
_ = locale.setlocale(locale.LC_ALL, loc)
except locale.Error:
continue
alt_digits = locale.nl_langinfo(locale.ALT_DIGITS)
if alt_digits:
print(loc, len(alt_digits), alt_digits) On Linux I now get
|
Oh I get that - I didn't even know it existed before the test started failing :).
It doesn't crash, only the test fails with:
I ran your script (with the
Before, it looked like this (3.13.0):
|
Thank you. Indeed, this looks like semicolon separated correct values.
|
Makes sense, although I think that if we want the tuple (which is indeed nicer on the Python side), we can implement alternative parsing (for Solaris and possibly other more compliant platforms) that uses |
It is interesting that a similar issue was fixed in Perl at the beginning of this year (Perl/perl5#21833). They return a single string, replacing null characters with semicolons. Actually, they support also other separators, but I do not think there is a reason to do this. |
… a string again This is a follow up of pythonGH-124974. Only Glibc needed a fix. Now the returned value is a string consisting of semicolon-separated symbols on all Posix platforms.
… a string again (pythonGH-125774) This is a follow up of pythonGH-124974. Only Glibc needed a fix. Now the returned value is a string consisting of semicolon-separated symbols on all Posix platforms. (cherry picked from commit dcc4fb2) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
… a string again (pythonGH-125774) This is a follow up of pythonGH-124974. Only Glibc needed a fix. Now the returned value is a string consisting of semicolon-separated symbols on all Posix platforms. (cherry picked from commit dcc4fb2) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
ALT_DIGITS is a glibc specific item. It is supported by Python (there is an explicit list of supported items), but the result is not correct.
From The GNU C Library Reference Manual:
This value is only defined in few locales: az_IR, fa_IR, ja_JP, lzh_TW, my_MM, or_IN, shn_MM.
But Python returns only one digit.
This is because
nl_langinfo(ALT_DIGITS)
in C returns a string with embedded null characters.How should we fix it?
What should we return if the value is not defined (in most locales) -- empty string (current behavior), empty tuple or None?
cc @methane
Linked PRs
The text was updated successfully, but these errors were encountered: