I've been thinking about the several cases where you know do something like b"".join([arg, int2byte(arg2)]).

I think this can be really error prone if you don't have the proper linting tooling.

Have you considered something like this?

def createPacket(*args):
	packet = bytearray()
	for arg in args:
		if isinstance(arg, int):
			packet.append(arg)
		elif isinstance(arg, bool):
			packet.extend(boolToByte(arg))
		elif isinstance(arg, collections.abc.ByteString):
			packet.extend(arg)
		else:
			raise TypeError
	return packet

The usage of that will end up like:

createPacket(
  data[2], # an int
  data[3:6], # bytes
  b"/x67", # bytes
  "/75", # oops a unicode string, linting wont catch me.
)

I think that it hides the problem. At least with b"".join you know that everything in the list hast to be bytes (or 'bytes-like'). With a function like this, you could easily be convinced into thinking it automatically converted a case that it didn't. That said, I think the b"".join syntax is quite ugly.

Braille input fails because braille input module still calls unichr.

Thanks @josephsl I'll look at this.

The whole point of writeSize was precisely that HID reports must be a specific size, but not all packets use the full size. So, I think this warning should not be logged at all.

@jcsteh I've been looking at the docs and haven't noticed this specified in relation to WriteFile

There is this comment in the code:

# Reading any less than caps.InputReportByteLength is an error.
# On Windows 7, writing any less than caps.OutputReportByteLength is also an error.

But it doesn't tell us what error or where to get information on it. I'll look into this more on Monday, perhaps there is more information in the original commit messages / PR.

My concerns:

• A writeSize of less than the buffer is going to result some data not being sent to the device. I suspect this is not the case, it would likely stop devices from working.
• A writeSize of more than the buffer is going to result in reading past the end of the buffer, sending garbage.

If write size must be a fixed size, then we should be altering the size of the buffer to match and padding with something, or doing multiple writes.

I'm merging in current threshold_py3_staging, so we can check appveyor status for this

I've just re-requested reviews from @LeonarddeR and @bramd.

Just a note, we would like to merge this as soon as we can to start getting broader testing. Please focus reviewing efforts on looking for bugs / mistakes.

I have tested the following driver/display combinations over USB:

Successfully used an Orbit Reader to read and navigate with NVDA, in both bluetooth and USB HID. Was also able to type braille input with #9835 merged into this branch.

Successfully read / navigated / typed on Baum Refreshabraille 18 with both USB and blutooth.

Was the idea for this pr to also convert brailleInput.py?

Yes, actually, it seems I missed it. Perhaps we merge these two PR's then I'll take another look through brailleInput.py looking for any other issues.

I tested the following displays over USB:

• Freedom Scientific Focus blue
• HumanWare Brailliant BI 40 (serial and HID)

These work fine after applying the fixes in #9839