search

doceme / py-spidev

MIT License
461 stars 203 forks source link

Standardise on one approach to numeric parsing, drop Long support from Python 2.x #98

Open Gadgetoid opened 4 years ago

Gadgetoid commented 4 years ago

Previously there was a mix of define-based polyfill and explicit version checking.

This change canonicalizes upon the latter, always using PyInt under Python 2.x and PyLong under 3.x.

As such this change will remove implicit compatibility with Long datatypes from the Python 2.x version of this library.

Since this (possibly unintended) compatibility witgh Python 2.x long types led to unexpected behaviour (see #34) it seems sensible to remove it and favour a TypeError.

Additionally, SPI doesn't support the transmission of any one value that might be represented by a Long in Python 2.x so this support was redundant.

I have also included a new folder of tests which run under both Python 2.x and Python 3.x. These are intended to validate (some not all) functionality of the spidev library and help avoid regressions (such as the one I introduced in #93 and discuss in #97). The included README.md documents, somewhat, how to run these properly.

This PR is raised as a draft because it's a bit meaty and potentially controversial. These tests are also incomplete and unable to run in a CI environment- that's something we should look into fixing.

Gadgetoid commented 1 year ago

@linuxtim since you've raised a ... relatively ... recent PR, I'd appreciate feedback on these changes if you have time.

It would be nice to move py_spidev forwards.

@doceme are you still out there? Would you consider transferring ownership of this repository to @pimoroni so I can deal with PRs and issues as they come and try to find some more maintainers?

linuxtim commented 1 year ago

The only thing I feel qualified to say on this is that anyone using Python 2.x at this stage is unlikely to be inconvenienced by this change - in the event that merging this PR caused an incompatibility for them they are likely to be able to continue to use a previous release of py-spidev. That is to say that the Python 2.x ecosystem is pretty much stationary at this point, and many (most?) libraries have dropped 2.x support entirely, so they are unlikely to have any dependency problems which force them to use such a new release.

Gadgetoid commented 1 year ago

I am not averse to simply dropping all Python 2.x support, and bumping the required version in setup.py up to 3.x. That would ensure that 2.x users get an older, compatible package and we don't have to worry about legacy junk anymore.

I think embedded is weird, though, there are still esoteric sysfs GPIO and Python 2.7 setups in use.