xfer, xfer2, writebytes wrong handling of longs

[EricPobot]

If the data to be sent contains items which type is long, they are are sent as 0x01 (checked with a logic analyzer) whatever is their value if they are not null. This is true even if the value fits in 8 bits.

Taking care of "casting" with int() when building the list of values avoids the problem.

Environment: Python 2.7.9 - RasPi2

[doceme]

Can you create a pull request for this? I'll take a look at it when I can.

[EricPobot]

Not sure to understand what you want me to do. I've not made any patch or alike. This is only a report about something I found while working on one of my projects.

[Gadgetoid]

What would you suggest is the correct handling of longs? There are certainly a few options:

• Treat as an error and raise accordingly (TypeError: "Must be list of type int")
• Use only the 8 LSBs ( bit mask with 0xFF ) and ignore the high bits of all inputs > 8bit width
• Split any input > 8bit width into multiple bytes - little or big endian?

The latter two as possible, and not uncommon, but would silently do stuff that may prove confusing or difficult to debug. Thus I'd suggest the former- the supplied list should be strictly type-checked to ensure it contains only ints and a TypeError thrown in case of failure.

Since list comprehension can fairly trivially address that concern if you don't care about truncation (ie xfer([int(x) for x in data]) it shouldn't be too painful.

[ericpascual]

I would vote for the first option, since as you wrote, doing things "under the cover" can create more problems than it solves, and quite hard to analyze most of the time.

My post being related to activities done quite long ago, I don't remember exactly how I've solved the issue, but there are chances I did it the way you suggest.