[Python-Dev] Type of range object members

["Martin v. Löwis"]

Greg Ewing schrieb:
>>> Also it means you'd pay a penalty every time you
>>> access it
>> That penalty is already paid today.
> 
> You'd still have that penalty, *plus* the
> overhead of bit masking to get at the value.

No, the penalty gets smaller if there is only a single type.
For example, abstract.c now has

                if (res && (!PyInt_Check(res) && !PyLong_Check(res))) {
                        PyErr_Format(PyExc_TypeError,
                                     "__int__ returned non-int (type
%.200s)",
                                     res->ob_type->tp_name);
                        Py_DECREF(res);
                        return NULL;
                }

Currently, if a long int is returned, it performs two subtype tests.
If the long type is dropped, the second test can go away. In this
specific code, there is no penalty for a representation flag, since
the value is not accessed.

Code that wants to support both int and long and needs the value
often does PyLong_AsLong these days, which will support int as well.
This currently reads

        if (vv == NULL || !PyLong_Check(vv)) {
                if (vv != NULL && PyInt_Check(vv))
                        return PyInt_AsLong(vv);
                PyErr_BadInternalCall();
                return -1;
        }

Notice that this has two checks if this is an int, and both are subtype
checks. With a single type, this would become

        if (vv == NULL || !PyInt_Check(vv)) {
                PyErr_BadInternalCall();
                return -1;
        }
        if (!vv->ob_size)
                return PyInt_AsLong(vv);

Actually, the implementation of PyInt_AsLong might get inlined;
it currently starts with a third PyInt_Check.

So overall, I would expect that a single type would improve performance,
not decrease it.

As you say, any change is likely not noticeable in performance, though,
either way.

Regards,
Martin