Omit asyncio.timeout from SIM117

[maltevesper]

While I generally agree with SIM117 (combine with statements where possible), I am wondering if there are cases where there should be exceptions to the rule, in particular asyncio.timeout comes to mind.

I.e. I find the following clearer

async with asyncio.timeout(0.2):
    async with line_processor:
        await line_processor.stop(0)

Less clear in my opinion:

async with asyncio.timeout(0.2), line_processor:
    await line_processor.stop(0)

While this is a minor cosmetic issue, I am wondering if this warrants a configuration option (a list of contextmanagers for which to ignore SIM117), or is to much of an edge case to consider complicating the configuration.

For now I ignore SIM117 for tests, which is the main case in which I trigger these.

[charliermarsh]

This seems like a reasonable suggestion -- I agree that collapsing the timeout here is awkward, since semantically it's meant to be wrapping the inner async with rather than peer to it. We could start just by omitting asyncio.timeout, and parameterize it later on if there's more need.

[charliermarsh]

PR welcome if you're interested :) The changes would be in multiple_with_statements, we'd want to check if the with_parent has a single item that matches asyncio.timeout.

[zanieb]

If we're going with the spirit of this change, we should probably also include AnyIO/Trio's move_on_after, fail_after, move_on_at, fail_at, and maybeCancelScope.

[maltevesper]

I will happily have a go at a PR this week (am a little busy)

Locks crossed my mind as a possible further candidate for "more explicit scoping", but I will stick with timing for starters.

[charliermarsh]

Awesome, just ask here or in Discord if you have any questions.