Skip to content

Long/Int confusion in Python 2.x #97

@Gadgetoid

Description

@Gadgetoid

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:

#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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions