The answer to that question depends on how the block maintainers feel about what environments they expect this test to be runnable under. I lightly teased kwolf once about an "ancient" version of pylint they were running, but felt kind of bad about it in retrospect: the tests I write should "just work" for everyone without them needing to really know anything about python or setting up or managing their dependencies, environments, etc.
(1) We can use it the very moment it is released if you're OK with running 'make check-dev' from the python/ directory. That script sets up its own virtual environment and manages its own dependencies. If I set a new minimum version, it will always use it. (Same story for 'make check-tox', or 'make check-pipenv'. The differences between the tests are primarily on what other dependencies they have on your environment -- the details are boring, see python/Makefile for further reading if desired.)
(2) Otherwise, it depends on how people feel about being able to run this test directly from iotests and what versions of mypy/pylint they are using. Fedora 33 for instance has 0.782-2.fc33 still, so I can't really "expect" people to have a bleeding-edge version of mypy unless they went out of their way to install one themselves. (pip3 install --user --upgrade mypy, by the way.) Since people are used to running these python scripts *outside* of a
managed environment (using their OS packages directly), I have largely
made every effort to support versions as old as I reasonably can -- to
avoid disruption whenever I possibly can.
So, basically, it kind of depends on if you want to keep 297 or not. Keeping it implies some additional cost for the sake of maximizing compatibility. If we ditch it, you can let the scripts in ./python do their thing and set up their own environments to run tests that should probably "just work" for everyone.297 could even just be updated to a bash script that just hopped over to ./python and ran a special avocado command that ran /only/ the iotest linters, if you wanted. I just felt that step #1 was to change as little as possible, prove the new approach worked, and then when folks were comfortable with it drop the old approach.