[Python-Dev] various unix platform build/test issues

[Guido van Rossum]

> [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.

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/)