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