Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
gh-131666: markanext_awaitable.close as aMETH_NOARGS instead ofMETH_VARARGS#131671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
gh-131666: markanext_awaitable.close as aMETH_NOARGS instead ofMETH_VARARGS#131671
Uh oh!
There was an error while loading.Please reload this page.
Conversation
1393bd3 intopython:mainUh oh!
There was an error while loading.Please reload this page.
| returnself | ||
| anext_awaitable=anext(A(),"a").__await__() | ||
| self.assertRaises(TypeError,anext_awaitable.close,1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
this results in an unawaited coroutine warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
fixed here#131708
…ead of `METH_VARARGS` (python#131671)
…ead of `METH_VARARGS` (python#131671)
Uh oh!
There was an error while loading.Please reload this page.
It's not really an issue because the underlying coroutine wrapper will raise a TypeError, so there won't be a different exception raised now. It's just that instead of "coroutine_wrapper.close taskes no argument", we have "anext_awaitable.close takes no argument".
anextawaitable_close()should be aMETH_NOARGSnotMETH_VARARGS#131666