When I set a timeout like this:

pyserial just retries reads like this:

I need to be able to know, when the read has timed out to resend my last message. Please raise a TimeoutError, so I can use pyserial like this:

I think that it is unpythonic to silently drop errors like a timeout. When a user of pyserial invokes a read(), the expected outcome is that it returns the data that has been read. So hitting the timeout is an error.

I found a workaround of using threads that communicate over queues:

You can detect that there was a timeout by checking the length of returned bytes versus the number of bytes requested. It is more like an EOF in Python, rather than a timeout error. That is also how some protocols are using the timeout, as packet delimiter.

An exception would be inconvenient in many cases. E.g. consider reading more than one byte but fewer arrive, the timeout strikes. Then you'd still expect to get the bytes, but how? Attached to the exception? Probably not where most people would expect to find data. When they would be returned with the current read() call, then the timeout exception would need be raised in the next call which is certainly also not what one would expect.

Thanks for your reply, @zsquareplusc. Checking the length of the returned bytes did not work for me. console.read() timed out repeatedly and there were never any bytes returned.

If I requested a specified number of bytes with a timeout, I would either expect that exact number of bytes or an exception. I am not sure if it would also be OK to return all bytes that have been read up to the timeout. That would definitely need to be documented and users would need to check whether the received data is complete. I think there is little value in aborted data, because the timeout can strike at any given instance, so users would need to program every eventuality. In practice this means to handle as many cases as characters requested. Restarting the communication should be easier to program in most cases.