This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Clearer assertion error
Type: Stage: patch review
Components: asyncio Versions: Python 3.10, Python 3.9, Python 3.8, Python 3.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: aeros, asvetlov, chris.jerdonek, eric.smith, mhils, pgjones, udifuchs, yselivanov
Priority: normal Keywords: patch

Created on 2020-03-31 11:34 by pgjones, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 19240 open pgjones, 2020-03-31 11:35
Messages (6)
msg365378 - (view) Author: Phil (pgjones) * Date: 2020-03-31 11:34

I recently came across this error, which I now know how to fix. I think the error can be clearer and I've a PR which I think does so.
msg365381 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-03-31 11:59
Do we really want this to be just an assert, or do we want to raise another type of exception? I think it's showing a real programming error that we wouldn't want to throw away with -O.
msg365568 - (view) Author: Kyle Stanley (aeros) * (Python committer) Date: 2020-04-02 04:17
> Do we really want this to be just an assert, or do we want to raise another type of exception?

IMO, we should look into converting this into an exception. Mistakenly having a task await StreamWriter.drain() at the same time as another is calling StreamWriter.write() does seem like a reasonable programming error that should preferably have an informative error message. Optimally, assertions shouldn't occur from normal programming errors in production.

The tricky part is figuring out how to implement it properly. I'm not 100% certain that we can make any guarantees that when the _drain_waiter future hasn't been cancelled and not set to None that someone is mistakenly doing the above. It could potentially trigger from other errors.

Either way though, I think just adding a message to the assert could end up being misleading if someone else encounters this in production for another reason. Instead, I think we could leave a comment there for now and in the long term figure out how to properly implement the exception or warning. We also need a reliable way to reproduce it, mainly for the purpose of writing a new test to ensure the exception is correctly triggered when someone makes the above programming error.
msg369332 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2020-05-19 10:17
How about we review Phil's PR, which adds a message to the assertion. And then we can keep this issue open to discuss converting the assertion to an exception. I think Phil's PR is an improvement.
msg376643 - (view) Author: Udi (udifuchs) Date: 2020-09-09 15:28
I don't see anything in the documentation of drain() that states that it cannot be called from multiple tasks.

I'm also not sure why this assertion is necessary. If self._drain_waiter is already set, could the other task just await on it?
msg414142 - (view) Author: Maximilian Hils (mhils) * Date: 2022-02-27 06:48
I'm pretty sure this issue is a duplicate of bpo-issue29930.
Date User Action Args
2022-04-11 14:59:28adminsetgithub: 84305
2022-02-27 06:48:02mhilssetnosy: + mhils

messages: + msg414142
versions: + Python 3.10
2020-09-09 15:28:11udifuchssetnosy: + udifuchs
messages: + msg376643
2020-05-19 10:17:56chris.jerdoneksetnosy: + chris.jerdonek
messages: + msg369332
2020-04-02 05:46:24SilentGhostsetversions: - Python 3.5, Python 3.6
2020-04-02 04:17:51aerossetnosy: + aeros
messages: + msg365568
2020-03-31 11:59:01eric.smithsetnosy: + eric.smith
messages: + msg365381
2020-03-31 11:35:32pgjonessetkeywords: + patch
stage: patch review
pull_requests: + pull_request18598
2020-03-31 11:34:58pgjonescreate