Specify Python version for auto-formatters

[davidculley]

Told isort, black and ruff which version(s) of Python to assume.

These tools shall not change code such that it isn't recognized by Python 3.9, the version we currently use.

[dae]

Out of curiosity:

• is the lack of these directives currently causing any troubles?
• have you found ruff useful on the codebase?

[davidculley]

have you found ruff useful on the codebase?

Yes, definitely.

is the lack of these directives currently causing any troubles?

No, I don't think not setting them would cause troubles. It'd just be an unnecessary restriction.

For example, ruff insists on keeping the code compatible with Python 3.8 if the version is not explicitly set (source). It won't make suggestions for how to modernize the code if Python 3.8 won't understand them, which unnecessarily keeps legacy code in the codebase.

Regarding isort, I don't think it would result in problems, it's just that it's not semantically correct. For example, the module tomllib was added to the standard library only in Python 3.11. If someone were trying to use that module (even though it won't be understood by Python 3.9), isort would put the import tomllib in the first section (for the standard library) rather than in the second section (for the third-party modules), even though Python 3.9's standard library does not contain a module named tomllib. Let's further say that someone is unhappy that tomllib is not available for Python 3.9 and develops his/her own package compatible with 3.9 that he/she self-hosts and unfortunately also names tomllib. After a pip install from his/her own server, the import tomllib would falsely be placed with the standard library modules rather than the third-party modules if he/she uses Python 3.9 but does not tell isort to assume 3.9. I don't think it causes troubles, it's just not semantically correct and unnecessarily leads to confusion. This is just one example how things could get wrong.

[dae]

Appreciate you elaborating.

have you found ruff useful on the codebase?

Yes, definitely.

Could I trouble you to elaborate? We could potentially add it to the build process if it is adding sufficient value. We won't be able to remove pylint in the near future however, so this would be more about catching certain types of errors faster (assuming ruff is not bring stuff to the table pylint isn't, apart from speed).