You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
asyncio.sleep(float('nan')) does not raise ValueError #105331
time.sleep(float('nan')) raises ValueError, but asyncio.sleep(float('nan')) is valid and sleeps for 0. This seems bad, and asyncio.sleep should probably also raise ValueError.
importasyncioimporttimetry:
time.sleep(float('nan'))
exceptValueError:
print("time.sleep raised ValueError")
asyncdeffoo() ->None:
awaitasyncio.sleep(float('nan'))
print("asyncio.sleep does not raise any error")
asyncio.run(foo())
$ python foo.py
time.sleep raised ValueError
asyncio.sleep does not raise any error
time.sleep and asyncio.sleep do differ in behaviour when it comes to negative numbers and changing that behaviour was considered a breaking change without strong reason: #83879 nan feels like it should very rare to be passed intentionally, but the potential gain might also be small enough that this isn't worth fixing.
time.sleep and asyncio.sleep do differ in behaviour when it comes to negative numbers and changing that behaviour was considered a breaking change without strong reason: #83879
Hm, I expect at this point there is probably plenty of working code out there that passes a negative delay to asyncio.sleep (perhaps the result of trying to sleep until some target time that's slightly in the past).
I don't see how NaN could be the result of such a computation, so I agree NaN is a "weird" argument (and leads to undefined behavior).
So I think I can only approve of the NaN check.
Reacted by Zac Hatfield-Dodds, John Litborn and Kiera Reed
Activity
sobolevn commentedon Jun 6, 2023
It is also different for negative values.
For example:
and
jakkdl commentedon Jun 6, 2023
Yes, I wrote
kumaraditya303 commentedon Jun 9, 2023
I don't think we should change it at this point, I can accept a docs improvement for this but I'm -1 on changing the behavior.
Zac-HD commentedon Jun 9, 2023
fwiw I'd expect it to follow whatever
time.sleep()does with weird arguments, and think that there's a pretty strong argument in favor of consistency.gvanrossum commentedon Jun 10, 2023
Hm, I expect at this point there is probably plenty of working code out there that passes a negative delay to
asyncio.sleep(perhaps the result of trying to sleep until some target time that's slightly in the past).I don't see how NaN could be the result of such a computation, so I agree NaN is a "weird" argument (and leads to undefined behavior).
So I think I can only approve of the NaN check.
pythongh-105331: Fix asyncio.sleep() bug
pythongh-105331: move import math to the toplevel
pythongh-105331: Improve the content description of the error message
pythongh-105331: Improve description to more detailed
pythongh-105331: Improve description to more detailed
pythongh-105331: Improve description to more detailed
pythongh-105331: Fix the indentation change
pythongh-105331: Add test for asyncio.sleep() delay is nan
pythongh-105331: Move check delay is nan section after delay <= 0 sec…
pythongh-105331: Add description for versionchanged
gh-105331: Change `asyncio.sleep` to raise ``ValueError` for nan (#10…
Merge branch 'main' into modulelocals