2.2a0: latest unicode change breaks test_unicodedata
In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the methods test: test test_unicodedata failed -- Writing: '00c22b40a906a1a738012676c9feaedfc6be20 d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18' python Lib/test/test_unicodedata.py Testing Unicode Database... Methods: 00c22b40a906a1a738012676c9feaedfc6be20d9 Functions: 4db70de42a8f2de6236242949579fe0e80e7c34a API: ok (Tru64 Unix, Compaq C) -- Mark Favas - m.favas@per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA
[Mark Favas]
In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the methods test:
test test_unicodedata failed -- Writing: '00c22b40a906a1a738012676c9feaedfc6be20 d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18' ... (Tru64 Unix, Compaq C)
Reproduced identically on Windows (guess *everything* isn't the fault of Compaq's compiler <wink>). I assume this has something to do with the very recent Unicode "optimization" patch. Mystery: since running the test suite before committing the change would have caught this, how did the bug get into the CVS tree? Since it appears test_unicodedata is skipped under Unix when building the quicktest target, is this due to people mechanically using quicktest instead of test? Then that's a second optimization bug <0.6 wink>.
participants (2)
-
Mark Favas -
Tim Peters