[Tim Peters wrote about the test_unicodedata.py glitch]: > > [MAL] > > It is fixed in CVS ... don't know if the patch made it into > > the release though. The new test now uses UTF-8 as encoding > > which is endian-independent. > > Alas, it was not in the release. I didn't even know about it until after > the installers were all built and shipped. Score another for last-second > improvements <0.5 wink>. You're right. This shouldn't have been applied so close to the release date/time. Looks like all reviewers work on little endian machines... > Very, very weird: we all know that SHA is believed to be cryptologically > secure, so there was no feasible way to deduce why the hashes were > different. But I was coming down with a fever at the time (now in full > bloom, alas), and just stared at the two hashes: > > good: b88684df19fca8c3d0ab31f040dd8de89f7836fe > bad: e052289ecef97fc89c794cf663cb74a64631d34e > > Do you see the pattern? Ha! I did! They both end with "e", and in my > fuzzy-headed state I immediately latched on to that and thought "hmm ... 'e' > is for 'endian'". Else I wouldn't have had a clue! Well, let's think of it as a hidden feature: the test fails if and only if it is run on a big endian machine... should have named the test to something more obvious, e.g. test_littleendian.py ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4