> [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").
[Tim]
> 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.
Good idea.
> 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);
No, that code is guarded by a test whether tp_as_number == NULL or
nb_float is NULL; it issues the expected message "a float is required".
[Neal, later]
> The tp_as_number check in default_3way_compare pretty bogus though,
> IMHO. With the new type changes a lot of types have a tp_as_number
> slot. I think the compare code needs to change.
Yes, but how?
--Guido van Rossum (home page: http://www.python.org/~guido/)
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