Tim Peters wrote:
> 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.
It was not necessary but I thought it was cleaner. Here is the
important part of the patch:
diff -u -r2.106 abstract.c
--- Objects/abstract.c 5 Nov 2002 18:05:49 -0000 2.106
+++ Objects/abstract.c 17 Nov 2002 18:28:22 -0000
@@ -639,12 +639,6 @@
PyObject *
PyNumber_Remainder(PyObject *v, PyObject *w)
{
- if (PyString_Check(v))
- return PyString_Format(v, w);
-#ifdef Py_USING_UNICODE
- else if (PyUnicode_Check(v))
- return PyUnicode_Format(v, w);
-#endif
return binary_op(v, w, NB_SLOT(nb_remainder), "%");
}
The problem with special casing "unicode" and "str" is that subclasses
could not override __mod__. I think it would also work to remove the
tp_as_number slot and then do the PyUnicode_Check and PyString_Check
after trying binary_op().
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.
Neil
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