Rule codes do not respect the Flake8 specification, making yesqa break flake8-async noqa statements

[PLPeeters]

I tried using yesqa in conjunction with flake8-async in my pre-commit hooks, but I ran into an issue where yesqa would not play nice with the flake8-async rule codes. I raised an issue there initially, but was told the flake8-async codes do not abide by the Flake8 requirements, which unfortunately turns out to be correct.

Quoting the docs:

A 3 letters entry point prefix followed by 3 numbers (i.e. ABC123) is currently the longest allowed entry point name.

Question is: what now? Changing the prefix for the codes isn't exactly a non-breaking change, but then again not respecting the requirements set out by Flake8 probably ought to be considered a bug as it might lead to errors somewhere down the line.

In a way, I'm wondering if the best solution here isn't challenging this limitation with the Flake8 maintainers as it does seem arbitrary, especially since your 5-letter prefixes seem to be working just fine. Thoughts?

[jakkdl]

See extensive discussion in #230 and mentioned issues/pull requests. tl;dr we think it's a dumb limitation, that previously wasn't enforced, so we intentionally don't adhere to it.

yesqa is from the same developer as flake8 itself, and after previous interactions with them I'm very skeptical that they'll relax the requirement.

[PLPeeters]

Can't say I disagree with your stance here... I really can't wrap my head around him deciding to break something that works, especially when Flake8 has this big of an ecosystem around it. I guess it's a nice reminder about the risks that come with using someone else's software, but damn.

I really wonder what it will take to change his mind, because it clearly must be changed, unless we all missed a non-debatable valid reason for this change.

[Zac-HD]

An internal plugin I maintain monkeypatches this problem away:

# flake8 6.0+ limits the number of letters in a code; monkeypatch that away
_permissive_regex = re.compile("^[A-Z]{1,}[0-9]{0,}\Z")
flake8.defaults.VALID_CODE_PREFIX = _permissive_regex
flake8.options.config.VALID_CODE_PREFIX = _permissive_regex

I'm not suggesting that we add this to flake8-async or anything, but I'm still fine with ignoring this new restricting in the short term, and likely just moving to ruff in the long term 😞