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

Neil Schemenauer nas@python.ca
Tue, 18 Feb 2003 08:03:36 -0800


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