Closed nileshpatra closed 1 month ago
I noticed some similar issues with ssf: https://github.com/snoopyjc/ssf/issues/17
stemming from: https://github.com/python-babel/babel/releases/tag/v2.14.0
Locale.number_symbols will now have first-level keys for each numbering system. Since the implicit default numbering system still is "latn", what had previously been e.g. Locale.number_symbols['decimal'] is now Locale.number_symbols['latn']['decimal'].
@nileshpatra Considering all of our tests are green on master
here, sounds like the Debian build is doing something differently. Can you share some verbose logs or such?
@Alex-ley-scrub That's unrelated – but as mentioned in the changelog, the format of .number_symbols
has changed from 2.13 to 2.14 to allow for other numbering systems than Latin. number_symbols
's documentation has had an admonition that the format may change between Babel versions since 2016, and now it did 😄
Hi @akx
Considering all of our tests are green on master here, sounds like the Debian build is doing something differently.
I suspect this has got something to do with tzdata version and the changes thereof. Is is possible to know what version of tzdata the CI pulls in? In debian it is 2023d-1 for the log that I linked to.
Can you share some verbose logs or such?
Will py.test-3 --verbose
help you here?
As far as I can see, none of the errors above should be related to tzdata
, but the CLDR data. Are you sure you're pulling and converting the correct CLDR data (make import-cldr
)?
I think so - we are using babel's tarball directly off github releases which has .dat files processed already. We don't have to pull and convert at our end - do we?
@nileshpatra Um... what tarball is that? The GitHub release for 2.14.0 has no sdist TAR.
@akx oops, seems like I gave an incorrect response w/o properly checking - sorry for that! You're right indeed, there's no sdist.
In debian, we generate .dat files via: python3 scripts/import_cldr.py /usr/share/unicode/cldr/common
and the version of unicode-cldr-core
in debian is 44.0
while babel pulls 43.0
as per
https://github.com/python-babel/babel/blob/master/scripts/download_import_cldr.py#L12
I suppose this is the difference -- do you think babel can be adapted to latest CLDR data?
@nileshpatra Sure, the work can be done to have Babel use CLDR 44, but that would be for Babel 2.15. Babel 2.14 uses CLDR 43 (https://github.com/python-babel/babel/pull/1043).
Ack, I will wait for a new release then
The freshly released Babel 2.15.0 uses CLDR 44. 🎉
The next version will use CLDR 45 when #1077 gets merged.
Overview Description
While upgrading the Debian package to latest version I am observing a bunch of test failures on some locales due to minor changes. I'm not sure if the expected output should be changed for these assertions.
Steps to Reproducewhere I have no idea
if it makes sense to simply skip/patch.
Run the test suite with:
LC_ALL=C py.test-3
Actual Results
Expected Results
All tests should pass
Additional Information
Version info:
python3: 3.12.1 pytest: 7.4.4 tz: 2023.3.post1-2 freezegun: 1.2.1 unicode-cldr-core: 44-0.1 tzdata: 2023d-1