-
Notifications
You must be signed in to change notification settings - Fork 206
Description
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:
Line 58 in 3239755
| #define PyInt_FromLong PyLong_FromLong |
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.