Jeremy Stanley wrote:
[...] Oof, yes I guess it's high time to discuss this (sorry if there was a prior ML thread about it which I missed). So I guess the options I can see are:
A. keep running woefully outdated flake8 and friends (isn't working)
To be fair, option (A) *is* working, as long as you don't use f-strings. So we could just say that we should not use certain new language features. However, the error you get when you try using them is very confusing, and I expect more and more people to hit it as we move forward.
B. overhaul hacking to work as a file-level analyzer plug-in
C. improve flake8 to support string-level analyzer plug-ins
D. separate hacking back out so it's no longer a flake8 plug-in
E. stop running hacking entirely and rely on other flake8 plug-ins
Anything else?
There is option (F) which is to explicitly add pyflakes>=1.4.0,<1.5 to projects that want to use f-strings (or to a new hacking version that projects will opt into). That will force flake8 to use pyflakes 1.4.0 instead of 1.2.3, while still remaining compatible with hacking. Looks like the only check 1.4.0 adds compared to 1.2.3 is duplicate dictionary keys[1], which hopefully should not trigger massive reports... As an example, see this DNM change which adds a f-string in patchset 1, fails pep8 tests with the cryptic error, but passes them in patchset 2 once pyflakes>=1.4.0,<1.5 is explicitly added in test-requirements: https://review.opendev.org/695653 This obviously kicks the can down the road, but at least avoids getting it onto mriedem's lawn... [1] https://github.com/PyCQA/pyflakes/commit/152ca182a603d7327925873db9a79579781... -- Thierry Carrez (ttx)