-
-
Notifications
You must be signed in to change notification settings - Fork 378
Add __main__ module with await-compatible console
#2407
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
Conversation
I recently learned that `python -m asyncio` drops you into an
interpreter session that knows how to deal with `await` expressions. For
example,
```console
$ python -m asyncio
asyncio REPL 3.10.6 [...] on darwin
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> await asyncio.sleep(1); print("hi") # prints after one second
hi
```
This quickly became an important part of my async debugging toolbox.
I've also been learning Trio recently, but I've been missing my async
console.
This PR takes the script from [`asyncio.__main__`][1] and adapts it to
use a Trio run loop. With this patch applied, users can run `python -m
trio` to drop into an interactive interpreter session that lets them
directly `await` Trio-based async expressions.
```console
$ python -m trio
Trio 0.21.0+dev, Python 3.10.6 [...] on darwin
Use "await" directly instead of "trio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import trio
>>> await trio.sleep(1); print("hi") # prints after one second
hi
```
[1]: https://github.com/python/cpython/blob/master/Lib/asyncio/__main__.p
I'm very new to Trio, so I'm sure my approach is suboptimal. In
particular, I'd really appreciate feedback from the team/ community on:
- not using `threading` with a brand new `trio.run` to evaluate
awaitable expressions. I found that if I simply used
`self.nursery.start_soon` in the same thread as `runcode`, `await`
expressions wouldn't get the chance to be evaluated until the session
was shutting down (might have been blocked by reading keyboard input,
if I had to guess). Could there be a solution in `trio`'s threading
tools?
- what documentation updates should accompany this PR
- what sort of tests I should add (since this change implements a brand
new code path that won't be touched by any existing or future usage of
`trio` itself, I wasn't sure if it would even be appropriate to _try_
and test it)
- anything else to align this addition to the Trio way!
Many thanks for your consideration.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2407 +/- ##
==========================================
- Coverage 99.64% 99.37% -0.28%
==========================================
Files 117 118 +1
Lines 17634 17682 +48
Branches 3172 3180 +8
==========================================
Hits 17572 17572
- Misses 43 91 +48
Partials 19 19
|
Adds a section to the end of the reference-core document that notes the existence of this new feature, what it's for, and how to use it. Fixes the broken `:mod:` link from my towncrier entry by instead linking to the new section in reference-core.
|
Given that #2972 has been merged, this PR should be closed, shouldn't it? (With |
|
Yeah it should have been. Thanks for the contribution nonetheless! |
|
Glad to see this feature has been added, and I'm happy to have played a (small) role in the solution! |
I recently learned that
python -m asynciodrops you into aninterpreter session that knows how to deal with
awaitexpressions. Forexample,
This quickly became an important part of my async debugging toolbox.
I've also been learning Trio recently, but I've been missing my async
console.
This PR takes the script from
asyncio.__main__and adapts it touse a Trio run loop. With this patch applied, users can run
python -m trioto drop into an interactive interpreter session that lets themdirectly
awaitTrio-based async expressions.I'm very new to Trio, so I'm sure my approach is suboptimal. In
particular, I'd really appreciate feedback from the team/ community on:
threadingwith a brand newtrio.runto evaluateawaitable expressions. I found that if I simply used
self.nursery.start_soonin the same thread asruncode,awaitexpressions wouldn't get the chance to be evaluated until the session
was shutting down (might have been blocked by reading keyboard input,
if I had to guess). Could there be a solution in
trio's threadingtools?
new code path that won't be touched by any existing or future usage of
trioitself, I wasn't sure if it would even be appropriate to tryand test it)
Many thanks for your consideration.