Long/Int confusion in Python 2.x

In think in #93 I've introduced a potential error or strangeness in Python 2.x by using PyLong_FromLong in lieu of PyInt_FromLong. Since we have a macro to smooth over this difference, I should probably use the latter:

https://github.com/doceme/py-spidev/blob/32397557f4edc073a48b6a1bafcfde4d4fd0a61f/spidev_module.c#L58

Using the following code in Python 2.7:

import spidev
import time

bus = spidev.SpiDev(0, 0)

bus.mode = 0
bus.lsbfirst = False
bus.max_speed_hz = 80 * 1000000

result = bus.xfer([int(x) for x in range(10)])

print(result)

results in:

[255L, 255L, 255L, 255L, 255L, 255L, 255L, 255L, 255L, 255L]

IE: It's given a list of integers, and returns a list of longs.

This means that we get new long objects for every byte in the result, rather than references to the internal integer array. (Python contains an array of integer objects for all known integers between -5 and 256)

See:

>>> a = 255L
>>> b = 255
>>> a is b
False
>>> a = 255
>>> b = 255
>>> a is b
True

Looking back at #34 suggests that things can potentially go awry the other way, too. The current check uses PyLong_Check whereas we have a define to smooth PyInt_Check to PyLong_Check. This means that under Python 2.x the library will happily accept Longs

Since we can't accept and return longs in Python 2.x- and because #34 suggests passing in longs has unexpected results in Python 2.x- it should probably fail with a TypeError if any long type numbers are passed in.

In the same vein, the codebase currently has a mix of the #define based polyfill and explicit version checking.

A good example is this:

https://github.com/doceme/py-spidev/blob/32397557f4edc073a48b6a1bafcfde4d4fd0a61f/spidev_module.c#L200-L214

Assuming we use PyInt_Check here, and that this is defined to be PyLong_Check under Python 3 then this can be simplified to:

    if (PyInt_Check(val)) {
        buf[ii] = (__u8)PyInt_AS_LONG(val);
    } else {
        snprintf(wrmsg_text, sizeof (wrmsg_text) - 1, wrmsg_val, val);
        PyErr_SetString(PyExc_TypeError, wrmsg_text);
        return NULL;
    }

This would drop implicit support of the long type in Python 2.

Since currently you can mix ints/longs in Python 2 and have the code behave in unexpected ways, failing with an exception when a Long is passed to any of the library methods or properties is probably a good idea. Although it may, conceivably, "break" existing (misbehaving) user code, at least it will be breaking it more explicitly.

doceme / py-spidev

Long/Int confusion in Python 2.x #97