[Guido, on again lumping numbers together]
> I think I can put this behavior back. (I believe that before I
> reorganized the comparison code, it seemed really tricky to do this,
> but after refactoring the code, it's quite easy to do.)
I can believe that; and I believe the "bugs" in 2.0 ended up somewhere in or
around the bowels of the xxxHalfBinOp-like routines (which were really
tricky to my eyes -- the interactions among coercions and comparisons were
hard to keep straight).
> My only concern is that under the old schele, two different numeric
> extension types that somehow can't be compared will end up being
> *equal*. To fix this, I propose that if the names compare equal, as a
> last resort we compare the type pointers -- this should be consistent
> too.
Agreed, and sounds fine! Save Barry a little work, though:
> ! /* Same type name, or (more likely) incomparable numeric types */
> ! return (v->ob_type < w->ob_type) ? -1 : 1;
That's non-std C in a way Insure complains about elsewhere; change to
return ((Py_uintptr_t)v->ob_type <
(Py_uintptr_t)w->ob_type) ? -1 : 1;
if-vendors-stuck-to-the-letter-of-the-c-std-python-wouldn't-
compile-at-all<wink>-ly y'rs - tim
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