[Neal Norwitz] > * AIX sorts numbers and strings in a different order than Linux: > > >>> 'ick' >= 0 # Linux > True > > >>> 'ick' >= 0 # AIX > False > > This causes failures for test_descrtut and test_random. It shouldn't. Regardless of platform, this should end up at the tail end of default_3way_compare(), resolved by the c = strcmp(vname, wname); line with vname "str" and wname "" (an empty string). But-- ick! --it doesn't, and not on any platform anymore. vname and wname are both empty strings now, so it goes on to compare the objects by memory address and the outcome is pure accident ... this is because rev 2.197 of stringobject.c gave string objects a non-NULL tp_as_number slot for the first time. The intent of the emtpy-string gimmick was to make all numeric objects "less than" all non-numeric objects (excepting None, which is less than every non-None value), in particular so that sorting a list would bring all the number-like thingies next to each other. Strings weren't intended to take part in this number gimmick too. Then again, comparison is so snaky it's hard to predict what it will do. In any case, this is incompatible with previous Python releases. Neil(S), was giving strings a tp_as_number slot necessary? Or just the least painful way to fix whatever bug it was fixing? I suppose the tail end of default_3way_compare could grow more special cases to exempt strings from being treated like numbers for the purpose of comparison.
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