Repository navigation
asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers #83879
Description
| BPO | 39698 |
|---|---|
| Nosy | @asvetlov, @1st1, @Marco-Sulla |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2020-02-20.19:17:33.548>
created_at = <Date 2020-02-20.11:44:23.841>
labels = ['type-bug', '3.9', 'expert-asyncio']
title = 'asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers'
updated_at = <Date 2020-02-26.19:46:37.563>
user = 'https://github.com/Marco-Sulla'bugs.python.org fields:
activity = <Date 2020-02-26.19:46:37.563>
actor = 'Marco Sulla'
assignee = 'none'
closed = True
closed_date = <Date 2020-02-20.19:17:33.548>
closer = 'yselivanov'
components = ['asyncio']
creation = <Date 2020-02-20.11:44:23.841>
creator = 'Marco Sulla'
dependencies = []
files = []
hgrepos = []
issue_num = 39698
keywords = []
message_count = 7.0
messages = ['362314', '362321', '362345', '362349', '362519', '362673', '362724']
nosy_count = 3.0
nosy_names = ['asvetlov', 'yselivanov', 'Marco Sulla']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39698'
versions = ['Python 3.9']
Activity
Marco-Sulla commentedon Feb 20, 2020
I think that also
asyncio.sleep()should raiseValueErrorif the argument is less than zero.asvetlov commentedon Feb 20, 2020
The ship has sailed, this change breaks a lot of existing code without a strong reason.
I recall very many cases in third-party libraries and commercial applications where a negative argument for asyncio.sleep() is processed as asyncio.sleep(0) without failure.
1st1 commentedon Feb 20, 2020
Yes.
It's a common thing to compute asyncio.sleep delay and sometimes it goes negative. The current behavior is part of our API now.
Marco-Sulla commentedon Feb 20, 2020
Source?
Marco-Sulla commentedon Feb 23, 2020
I see that many breaking changes was done in recent releases. I get only the ones for
asyncioin Python 3.8:https://bugs.python.org/issue36921
https://bugs.python.org/issue36373
https://bugs.python.org/issue34790
https://bugs.python.org/issue32528
https://bugs.python.org/issue34687
https://bugs.python.org/issue32314
So I suppose the ship isn't sailed yet.
Passing a negative number to a function that should sleep the task for x seconds is a mistake. And mistakes should never pass silently.
Furthermore, coherence matters. It's really confusing that two functions in two builtin modules that are quite identical have a different behavior.
IMHO, deprecating and then removing support for negative argument in
asyncio.sleep()is very much less breaking compared to issues bpo-36921 and bpo-36373 .1st1 commentedon Feb 25, 2020
I could not find a good source, sorry. I remember I had a complaint in uvloop to support negative timeouts, but I can't trace it.
That said, I also distinctly remember seeing code (and writing such code myself) that performs computation on timeouts and does not care if the end value goes below 0. It might be a weak data point but it's still a valid one.
Breaking code/APIs always has a price and we always try to have a very good explanation "why" we want to bother ourselves and users to break backwards compat. This one is not worth it IMHO.
We have more breaking API changes that are more substantial coming in future versions of asyncio. So I try to limit the impact by only breaking what's really necessary.
Marco-Sulla commentedon Feb 26, 2020
This is not a good statistics. Frankly we can't measure the impact of the change from these considerations. And furthermore,
asyncio.sleep()is used often, testing and mocking apart? I doubt it.Coherence and unhide mistakes are *very* strong points.
That said, I'm not so much interested in practice. Do as you wish. The problem is I always considered Python a very elegant programming language, and this behavior is not elegant at all. But, hey, amen.