[Python-Dev] various unix platform build/test issues (original) (raw)

Guido van Rossum guido@python.org
Tue, 18 Feb 2003 10:05:21 -0500

[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 testdescrtut and testrandom.

It shouldn't. Regardless of platform, this should end up at the tail end of default3waycompare(), 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 tpasnumber 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 tpasnumber slot necessary? Or just the least painful way to fix whatever bug it was fixing? I suppose the tail end of default3waycompare could grow more special cases to exempt strings from being treated like numbers for the purpose of comparison.

I forget what Neil's motivation was; SF bug #615506 doesn't really mention much for motivation. I suspect it's simply cleanliness.

Maybe PyNumber_Check() could be changed? This has been proposed before. It could check whether the type implements conversion to int, for example. Or it could check whether the type derives from a new-to-introduce abstract base class ("basenumber").

--Guido van Rossum (home page: http://www.python.org/~guido/)