Utilise pyupgrade in pre-commit hooks

[marksweb]

There may be good reason that it's not part of the hooks in use, but having seen #8226, it seems like a good idea to run pyupgrade in the pre-commit hooks. I can't see any existing discussion on it, besides dropping python 2 support in 2019.

Running an --all-files would prevent the need for people to go over the project with change like above and also catch all potential efficiency improvements.

Under the current project setup with python 3.5 support, the changes are fairly minor - only 28 files impacted. If python 3.5 support was dropped (👀), that expands to 48 files. So the reviews wouldn't be too painful, especially because some of these are actually resolved by #8226

Just revisiting this after someone raised the fact that Python 3.6 hits EOL towards the end of December, therefore dropping 3.5 is a no brainer & perhaps dropping 3.6 should also be considered if it's official security support has ended.

[tomchristie]

I'd rather we just make any changes at the point of removing older Python versions, rather than adding tooling to the workflow.

We could certainly consider dropping Python 3.5 at this point, yes. I'd be interested in seeing any neatening up changes which that would allow. If pyupgrade is a good tool from determining those, then that's great, but let's just use it as and when needed.

[tomchristie]

therefore dropping 3.5 is a no brainer

Oh in fact we're not running the test suite against 3.5 these days anyways. Are we still listing 3.5 as "supported" somewhere?

[marksweb]

Yeah 3.5 is in the classifiers;

https://github.com/encode/django-rest-framework/blob/master/setup.py#L101

And there is some <3.6 support here; https://github.com/encode/django-rest-framework/blob/master/tests/test_description.py#L162

[marksweb]

I'd rather we just make any changes at the point of removing older Python versions, rather than adding tooling to the workflow.

That's fair enough, I can appreciate that, though I would say that from the projects I've added pyupgrade to, it's an invisible part of the workflow as it will modify any python in pre-commit to ensure efficiency based on the target python version.

On this project all that it's really found to upgrade is string formatting, where it'll favour F strings and .format() when setting python 3.6+ as the target python version. You can see any changes it could make here; marksweb@ab0fdb0

On a side note, Adam Johnson has s similar tool for django itself, django-upgrade. Again a neat tool that can be added as a hook & you don't have to really worry about it.

But as you say, both can be used as & when wanted rather than being hooks on pre-commit.