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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#11841 fix pending futures #11890
base: trunk
Are you sure you want to change the base?
#11841 fix pending futures #11890
Conversation
for more information, see https://pre-commit.ci
… into support-pending-feature
please review |
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.
Many thanks for the changes.
I don't have experience with future
and it looks like the automated tests is not executed... so I can't do a proper review.
I left a few general comments regarding the PR.
I think the main change looks good... but I think that this PR needs improvement on documenting the changes and the tests
Thanks again
@ensuringDeferred | ||
async def test_fromCoroutineWithEnsureFuture(self) -> None: | ||
""" | ||
L{Deferred.fromCoroutine} should properly process pending futures |
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.
What does "properly" means ?
I don't know why this has no coverage.
Is this test executed?
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.
What does "properly" means ?
It means we should back control the event loop before we can call send
again. Not sure how to describe it.
And yes, this test is executed, at least locally, and without these changes is failed.
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.
It means we should back control the event loop before we can call send again.
Then the docstring should say those words, rather than "properly" :-)
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.
@glyph thanks! Good page.
@@ -0,0 +1 @@ | |||
`defer.Deferred.fromCoroutine` now correctly processes pending futures. |
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.
By reading the code, it looks like any @defer.inlineCallbacks
is affected by this change.
I don't have any experience with futures and coroutines... so maybe "correctly" makes sense for someone who has experience.
But I think that it would help add more information about what is considered "correctly"
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.
Okey, I will explain it in more detail.
@adiroiban, thanks for the review!
It's triggered locally, do you have any idea why it's not working in CI?
Sure, I will try to improve it. Also, who can look into this PR with futures and coroutines experience? |
A little more background for this issue.
Basically, the original |
I can reproduce it locally, working on it. |
Deferred.fromCoroutine intentionally does not support asyncio coroutines they have different cancellation semantics etc. To wait on a future you should explicitly call |
Deferred.fromCoroutine intentionally does not support asyncio coroutines they have different cancellation semantics etc. To wait on asyncio coroutines you should explicitly call |
I see, you support async/await but without asyncio. But it's very confusing in docs, https://docs.twisted.org/en/stable/core/howto/defer-intro.html#inline-callbacks-using-yield here we have the phrase:
also, the documentation includes examples only with |
This doesn't mean that only asyncio and trio are allowed to use them, nor that everyone using them is using asyncio or trio. |
Sure, but it's just in the context of confusion. Also, because we are using Maybe we should raise an exception if during follow coroutines we found Future? Because current errors like but still, my PR is working, I know it seems like will not be correct during the cancel case, but maybe is it possible to handle it? |
That is not accurate. I haven't evaluated the code here yet though, maybe it's great :-) |
|
Ah. Yes, the naming here is unfortunate. Clearly at least the documentation could use an improvement here. |
@exarkun, if I will try to solve |
I'll leave this to someone else to answer, I think. |
It's also |
It should fix #11841.
The main problem if
corouting.send
returns future in pending status which means we must back to the event loop and wait until it will be resolved. Otherwise, we will see the error "await wasn't used with future" which comes from thesend
code: https://github.com/python/cpython/blob/3.11/Modules/_asynciomodule.c#L1609 .We are doing the same thing if we receive
Deferred
but for some reason ignored asyncio futures. This PR does the same thing for pending futures as forDeferred
.Most problems come from
asyncio.ensure_future
function, which used by aiohttp. Without these changes not possible to use aiohttp inside Twisted even if you are using asyncio reactor and it reduces compatibility with tons of libraries.