[async-function-with-timeout] Disable check for asyncio before Python 3.11 (ASYNC109)

[vdwees]

Some (occasionally tangential) discussion is found here: #12353

Summary

Before, the diagnostic was raised for all supported versions of Python. However, asyncio only introduced asyncio.timeout in python version 3.11.

Now, the diagnostic is not raised when using asyncio with Python versions before 3.11

Test Plan

It's a policy tweak leveraging well-tested library features. I don't see an obvious need for an additional test, but I would be happy to receive guidance on how to add a test.

[codspeed-hq]

CodSpeed Performance Report

Merging #13023 will improve performances by 10.62%

_{Comparing vdwees:main (ad23c48) with main (cfe25ab)}

Summary

⚡ 1 improvements
✅ 31 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	vdwees:main	Change
⚡	linter/all-with-preview-rules[numpy/globals.py]	911 µs	823.5 µs	+10.62%

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Thanks. This does make sense to me. However, it does mean that the rule now deviates from the upstream rule (I'm not sure if flake8-async has access to the target Python version). @AlexWaygood what's your take on this?

https://github.com/python-trio/flake8-async/blob/225f15a98db4bb8ce4600127fd0fe90bc5c9c04b/flake8_async/visitors/visitors.py#L43C7-L60

It would be great if we can add a test demonstrating that this is working as expected (flags asyncio but not anyio)

You can add the test here

ruff/crates/ruff_linter/src/rules/flake8_async/mod.rs

Lines 18 to 39 in 45f459b

	#[test_case(Rule::TrioSyncCall, Path::new("ASYNC105.py"))]
	#[test_case(Rule::AsyncFunctionWithTimeout, Path::new("ASYNC109_0.py"))]
	#[test_case(Rule::AsyncFunctionWithTimeout, Path::new("ASYNC109_1.py"))]
	#[test_case(Rule::AsyncBusyWait, Path::new("ASYNC110.py"))]
	#[test_case(Rule::AsyncZeroSleep, Path::new("ASYNC115.py"))]
	#[test_case(Rule::LongSleepNotForever, Path::new("ASYNC116.py"))]
	#[test_case(Rule::BlockingHttpCallInAsyncFunction, Path::new("ASYNC210.py"))]
	#[test_case(Rule::CreateSubprocessInAsyncFunction, Path::new("ASYNC22x.py"))]
	#[test_case(Rule::RunProcessInAsyncFunction, Path::new("ASYNC22x.py"))]
	#[test_case(Rule::WaitForProcessInAsyncFunction, Path::new("ASYNC22x.py"))]
	#[test_case(Rule::BlockingOpenCallInAsyncFunction, Path::new("ASYNC230.py"))]
	#[test_case(Rule::BlockingSleepInAsyncFunction, Path::new("ASYNC251.py"))]
	fn rules(rule_code: Rule, path: &Path) -> Result<()> {
	let snapshot = format!("{}_{}", rule_code.noqa_code(), path.to_string_lossy());
	let diagnostics = test_path(
	Path::new("flake8_async").join(path).as_path(),
	&LinterSettings::for_rule(rule_code),
	)?;
	assert_messages!(snapshot, diagnostics);
	Ok(())
	}
	}

and you can use the code below (you have to change the path to the python file)

    #[test]
    fn async109_python_310_or_odler() -> Result<()> {
        let diagnostics = test_path(
            Path::new("flake8_async").join("path_to_test_File"),
            &LinterSettings {
                target_version: PythonVersion::Py310,
                ..LinterSettings::for_rule(Rule::AsyncFunctionWithTimeout)
            },
        )?;
        assert_messages!(diagnostics);
        Ok(())
    }

[AlexWaygood]

Thanks. This does make sense to me. However, it does mean that the rule now deviates from the upstream rule (I'm not sure if flake8-async has access to the target Python version). @AlexWaygood what's your take on this?

Yeah, this change definitely makes sense to me! There are third-party libraries backporting asyncio.timeout to earlier Python versions, but I think that's irrelevant to the changes this PR is making. So this looks good, once it has a test added!

[MichaReiser]

Perfect. Let's add a test and then merge this