Alex Waygood

I agree with @Pierre-Sassoulas. For the Mccabe plugin, I believe one of the primary motivations for the rule is to ensure that each function is testable in isolation. If a...

> Long match-case statements are very common while walking abstract syntax trees and are arguably way less complex than any other solution. I'd agree that match/case statements are more readable...

To me that just seems to be arbitrarily favouring some language constructs at the expense of others in the name of readability and style, which isn't what this rule is...

Other updates that are required - We should emit an error if `TypeVar`, `ParamSpec` or `TypeVarTuple` is imported from `typing_extensions` and the script targets py313+ (but not if the script...

Lastly, for `(Async)Generator` and `(Async)ContextManager`, we should recommend for the user to import them from `collections.abc` or `contextlib` rather than `typing_extensions` on Python 3.9-3.12 (and not emit a diagnostic at...

Hmm, I wouldn't do this for quoted annotations. I think it was definitely intentional in the original flake8 plugin for PEP-585 annotations in quotes to trigger this check, because otherwise...

> The messaging suggests you need this to avoid runtime errors. Huh, that's not how I've ever interpreted that message. The message is "Missing `from __future__ import annotations`, but uses...

> I'm now wondering if that should be a separate rule or part of FA100? Since the type _can_ be written more succinctly if you import `from __future__ import annotations`,...

Argh, I should have checked more thoroughly. Yikes, and sorry :( Yes, I didn't realise there was a distinction between `FA100` and `FA102`. In that case, we should indeed make...

> Confirmed that we still emit `FA100` on these. TYVM!