Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long/Int confusion in Python 2.x #97

Open
Gadgetoid opened this issue May 29, 2020 · 1 comment
Open

Long/Int confusion in Python 2.x #97

Gadgetoid opened this issue May 29, 2020 · 1 comment

Comments

@Gadgetoid
Copy link
Contributor

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.

@Gadgetoid
Copy link
Contributor Author

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

A good example is this:

py-spidev/spidev_module.c

Lines 200 to 214 in 3239755

#if PY_MAJOR_VERSION < 3
if (PyInt_Check(val)) {
buf[ii] = (__u8)PyInt_AS_LONG(val);
} else
#endif
{
if (PyLong_Check(val)) {
buf[ii] = (__u8)PyLong_AS_LONG(val);
} else {
snprintf(wrmsg_text, sizeof (wrmsg_text) - 1, wrmsg_val, val);
PyErr_SetString(PyExc_TypeError, wrmsg_text);
return NULL;
}
}
}

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant