trio.sleep(float('nan')) is valid and sleeps forever

[jakkdl]

trio.sleep(float('nan')) currently sleeps forever. Fixing it is pretty trivial by reordering the if statements but there's maybe other stuff that would break with NaN, and it might not be worth fixing a theoretical issue that idk if it might ever happen in reality - though I could imagine it biting somebody somewhere.

for reference: time.sleep() gives a ValueError, asyncio.sleep() sleeps for 0

[Zac-HD]

I think trio should raise a ValueError, and we should open a CPython issue to do the same in asyncio (if they haven't already considered it on the issue tracker).

[jakkdl]

time.sleep and asyncio.sleep do differ in how they handle negative numbers - and changing that was considered a breaking change with no strong reason for changing: python/cpython#83879
So I suspect they'd consider the nan case to be the same.

[jakkdl]

fail_after and move_on_after also raises ValueError on negative number - so seems reasonable that they also should error out on getting nan.

But somewhat surprisingly fail_at and move_on_at accept negative number without complaint - they do say the deadline "may be in the past", but a negative number (or nan) feels like it should maybe be treated like an error by them as well?

[oremanj]

AFAIK there is nothing to require that the values returned by trio.current_time() be positive, even though they usually are. So we can't forbid absolute deadlines that are below zero.