Add pyupgrade pre-commit hook #939
Conversation
|
As you might expect, I'm not a huge fan of this. It touches a lot of code for arguable benefit. Mostly, though, I would really like to see a working release make it out the door before we make too many more changes. |
I already released 3.2.2 with the most important bugfixes |
yagebu
force-pushed
the
pre-commit-pyupgrade
branch
from
1779b5c
to
1834faf
Compare
yagebu
force-pushed
the
pre-commit-pyupgrade
branch
from
1834faf
to
20fdcf8
Compare
| rev: v2.25.0 | ||
| hooks: | ||
| - id: pyupgrade | ||
| args: ["--py36-plus"] |
There was a problem hiding this comment.
Should be --py37-plus (though, in practice, that doesn't seem to change anything) since we no longer support python 3.6.
| @@ -87,7 +87,7 @@ def resolve_url_path(self, url_path): | |||
| return None | |||
|
|
|||
| def __repr__(self): | |||
| return "<%s %r>" % ( | |||
| return "<{} {!r}>".format( | |||
There was a problem hiding this comment.
There are a number of these cases where %-formatted strings are converted to .format() formatted strings rather than f-strings.
The pyupgrade README does say:
note: pyupgrade is intentionally timid and will not create an f-string if it would make the expression longer or if the substitution parameters are sufficiently complicated (as this can decrease readability).
That said, a lot of these cases seem like they are short enough that they would, in fact, be cleaner as f-strings. Should we manually convert them?
|
I'm closing this one. I still think it makes sense to have these lint rules but I think it makes more sense to use the newer, faster (not that pyupgrade wasn't fast enough already) and more powerful ruff. |
This hook automatically updates Python files with modern syntax, e.g., f-strings and sets.