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

[Tim Peters]

[Guido, on string-vs-number comparisons falling back to comparison
 by memory address now, instead of previous number < string behavior]

> 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").

The code in question doesn't invoke PyNumber_Check(), so changing that
wouldn't change behavior here.  The code in question could be changed to
start invoking PyNumber_Check, though.

Looks like, in the core, PyNumber_Check is used only by select_select and
poll_pool.  Try passing a string as the timeout arg to a select() call!
Looks to me like it will end up segfaulting here in PyFloat_AsDouble:

	fo = (PyFloatObject*) (*nb->nb_float) (op);

So the only PyNumber_Check() uses in the core appear to believe that
nb->nb_float isn't NULL if the test passes (but PyNumber_Check isn't
actually testing for that, and nb_float isn't always NULL when the test
passes).

NEWS sez:

"""
- PyNumber_Check() now returns true for string and unicode objects.
  This is a result of these types having a partially defined
  tp_as_number slot.  (This is not a feature, but an indication that
  PyNumber_Check() is not very useful to determine numeric behavior.
  It may be deprecated.)
"""