Remove the "RuntimeError: Timeout during packet send" error generated…

[geekguy-wy]

Remove the error generated when a packet send times out. Fixes issue #26.

[jerryneedell]

You can handle this error in your user code with a try/except. It should not normally occur and I think it should throw an error.
I’ll be interested in what others think.

[geekguy-wy]

Does that error indicate anything other than that the send timed out? Or, does it mean that the send did not finish or that some other condition that needs attention has occurred?

[jerryneedell]

Another option is to have send() return a Boolean indicating success or failure.
That way the user can check the status if the send(). This will impact my pending PR and I would prefer to implement it there and close this PR if you want to go that route.

[jerryneedell]

The error indicates some unexpected failure. I have seen them, but they have been rare. It is not clear to me why you should be seeing them. I’d prefer to investigate the root cause and see if we can until. The original library did not even check. As noted I only added the timeout because I was taught that such loops should have timeouts! You can also see if making the timeout longer helps.

[jerryneedell]

The more I think about it, the more i like the idea of having send() return a boolean:
True if successful (no timeout)
False if failed (timed out)
That way the user can check or ignore the status as desired. much like the proposed method of issuing no error. But it give the user the option of reacting without the need for a try/except.

[jerryneedell]

I recommend changing this to return a boolean indicting
True if success fun (no timeout)
False if failure (timeout)

just return not timed_out

this would be a non-breaking change.

[jerryneedell]

This looks good to me -- I have not tested it yet.I can do that later this afternoon.

[geekguy-wy]

The third commit updates the doc string.

[geekguy-wy]

Another option is to have send() return a Boolean indicating success or failure.
That way the user can check the status if the send(). This will impact my pending PR and I would >prefer to implement it there and close this PR if you want to go that route.

How does this impact your PR, Jerry?

[jerryneedell]

Another option is to have send() return a Boolean indicating success or failure.
That way the user can check the status if the send(). This will impact my pending PR and I would >prefer to implement it there and close this PR if you want to go that route.

How does this impact your PR, Jerry?

I'll be able to work with it. I have to think about it a bit but it may not require any changes. No reason to hold it up for me.

[jerryneedell]

I have tested this on a raspberry pi zero W -- the "simpletest" still runs normally and send() return True. I have not generated a failure, but I don't have any concerns with this change.
I think it is the right way to handle this.

[jerryneedell]

@caternuson @brentru any concerns or should I go ahead and merge this?

[jerryneedell]

Hearing no objections, I will go ahead and merge this PR in a little while.

[ladyada]

thanks!