Added link to `logot` in docs

[etianen]

I've just released logot, a testing library with some nice tools for testing highly-concurrent async code using log capture. It includes a trio integration, so it would be great to add it to the list of testing tools in your docs. ❤️

Here's a quick example of how the trio integration looks:

from logot import Logot, logged

async def test_app(logot: Logot) -> None:
   async with trio.open_nursery() as nursery:
      nursery.start_soon(app.start())
      await logot.await_for(logged.info("App started"))

Of course I'd welcome any feedback you have on the trio integration too! 🙇

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1d724a7) 99.64% compared to head (0384ed5) 99.64%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #2954 +/- ## ======================================= Coverage 99.64% 99.64% ======================================= Files 117 117 Lines 17634 17634 Branches 3172 3172 ======================================= Hits 17572 17572 Misses 43 43 Partials 19 19 ```

[etianen]

Thanks for the approval. Um... what happens now.. I can't actually merge! 😅

Just for the record, in general we recommend that you guarantee an await point in every async function: it looks like await_for doesn't.

Thanks for the feedback! Can you clarify what you mean here? The point of the early return is to avoid creating an Event and waiting on it when the expected log are already satisfied. Are you suggesting an await trio.lowlevel.checkpoint() call? What does that gain?

[A5rocks]

Yeah I'm suggesting that if _start_waiting returns None, then you await trio.lowlevel.checkpoint(). I don't think the benefits are massive for tests, but it's a convention we suggest: it's nice to know where cancellation will be propagated and when other tasks can run. (and certainty about both is worth a lot).

Thanks for the approval. Um... what happens now.. I can't actually merge! 😅

Yeah I'm just waiting for someone else to make sure it's fine. (Moreso I just don't want to unilaterally add something to the awesome libraries list :^)

[etianen]

Thanks for the explanation! I've not come across that convention before, but all my async work has been in asyncio. (I find the arguments for trio very convincing, btw, but I was already too deep on my various async codebases to change).

No rush on the PR... I just wanted to make sure you hadn't forgotten to press the button because I do that to people all the time on my projects! 🤦

[trio-bot[bot]]

Hey @etianen, it looks like that was the first time we merged one of your PRs! Thanks so much! :tada: :birthday:

If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:

• Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

• You'll be able to help us manage issues (add labels, close them, etc.)

• You'll be able to review and merge other people's pull requests

• You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

If you want to read more, here's the relevant section in our contributing guide.

Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you.

If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out!