-
-
Notifications
You must be signed in to change notification settings - Fork 338
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
Should Nursery.start_soon
return the trio.hazmat.Task
object
#1373
Comments
Yes, it's intentional:
|
I don't feel strongly about this so no need to defend your decision on the In case you're curious, here is the library I'm working in: https://github.com/ethereum/async-service/ The library provides a high level abstraction over using The need fo a reference to the I was able to work around this just fine using |
@pipermerriam Thanks for opening this issue! Today I learned more about trio (and async-service).
I don't think @njsmith was "defending" the decision, my reading was that he simply explained the rationale as you asked for it in your initial post. Did you feel that the tone was inappropriate? |
I was merely trying to signal that my reply wasn't intended to push for the API to change (but rather to explain the why behind my opening the issue). 😄 |
@pipermerriam Thanks for clarifying! Oh, I was about to forgot: nice avatar! 😄 |
Yeah, I'm a big fan of documenting design rationales like this; I feel like if you can't articulate the reason for something, then that's a good hint it might be wrong :-). So no worries about that.
Hmm yeah this has come up a few times. I'm not sure where we talked about it, but one idea was to have a version of a nursery that shields all background tasks from cancellation until the main I'm still confused about how |
In
asyncio
land a call toasyncio.ensure_future(my_coro())
returns aTask
object. This object is the same object that would be returned if you calledasyncio.current_task()
from withinmy_coro()
.In
trio
land,Nursery.start_soon(my_coro)
doesn't have a return value. The only way to get the running task that I could figure out was from within the running task by callingtrio.hazmat.current_task()
. This doesn't allow the scheduler to know about the task up-front.Was this an intentional design decision? I dug through issues and didn't find anything. Looking at the code it seems like a trivial thing to do by adding a single return statement here:
trio/trio/_core/_run.py
Line 902 in ff85406
The text was updated successfully, but these errors were encountered: