[Python-Dev] Type of range object members (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Aug 17 08:01:58 CEST 2006

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

More information about the Python-Dev mailing list