Skip to content
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

Add __main__ module with await-compatible console #2407

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

wbadart
Copy link

@wbadart wbadart commented Aug 26, 2022

I recently learned that python -m asyncio drops you into an
interpreter session that knows how to deal with await expressions. For
example,

$ 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__ 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.

$ 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

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.

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
Copy link

codecov bot commented Aug 26, 2022

Codecov Report

Attention: 48 lines in your changes are missing coverage. Please review.

Comparison is base (78c55aa) 99.64% compared to head (a43a9f3) 99.37%.

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              
Files Coverage Δ
src/trio/__main__.py 0.00% <0.00%> (ø)

wbadart and others added 6 commits August 27, 2022 10:28
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.
@CoolCat467 CoolCat467 mentioned this pull request Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants