Demonstration of old python code using pyupgrade

[Avasam]

This is a minimal run of pyupgrade to bring obsolete code and old standards up to par with Python 3.7. And enforce them through GitHub action. Same idea as #1990, but automated to Python 3.7. If have turned on all the --keep-percent-format flag and ignored adodbapi to keep changes to a minimum. (other flags had no effect on this codebase)

All python changes in this PR are automated, but here's an overview of the different types of changes seen in this PR:

• https://github.com/asottile/pyupgrade#format-specifiers + https://github.com/asottile/pyupgrade#printf-style-string-formatting + https://github.com/asottile/pyupgrade#f-strings --> #2122
• https://github.com/asottile/pyupgrade#redundant-open-modes --> #2121
• https://github.com/asottile/pyupgrade#unittest-deprecated-aliases --> #2088
• https://github.com/asottile/pyupgrade#oserror-aliases --> #2107 & #2088
• https://github.com/asottile/pyupgrade#invalid-escape-sequences --> #2112
• https://github.com/asottile/pyupgrade#super-calls --> #2106
• extraneous parens --> #2110
• https://github.com/asottile/pyupgrade#set-literals --> #2108 & #2109

[Avasam]

This has very marginal value IMO. […] it's also very opinionated about stylistic things and I'm not convinced we need yet another opinionated tool.

Understandable :) I still think there's a couple things shown in here that are worth considering in isolation. Even if they're not currently enforced by tooling (which could be covered by some more popular and configurable tools like Flake8/Ruff, even autofixed).

Namely:

• Redundant extra parenthesis (like ((foo))+bar)
• Use of obsolete / redundant aliases (like OSError aliases EnvironmentError, IOError, WindowsError, socket.error, select.error and mmap.error). They all mean the same thing since Python 3.3. Using arbitrarily different names can be confusing (one might think they are different errors).
• Use of deprecated aliases
• Invalid escape sequences
• More concise and less error-prone, "zero arguments" form of super calls
• (not shown here and opinionated) more concise f-strings interpolation over "% strings" or .format calls.
• Use of collections literals and comprehensions (there's some performance gains here, on top of often more concise syntax)

For your consideration to be completed in individual PRs.

[mhammond]

Yeah, I don't object to those change, but am less keen on having CI force this tool's opinions. I'm also mildly surprised none of the other tools seem to consider these worth noting?

[Avasam]

I'm also mildly surprised none of the other tools seem to consider these worth noting?

Black is only a formatter, not a linter. isort and pycln only deal with imports. I've already fixed in previous PRs a bunch of issues raised by mypy and pyright. Flake8/Ruff/pylint are the tools that would raise these kind of code smells / potential issues, whilst being configurable, but they are not currently used.

I've updated the title of the PR to reflect this more as a demo, I'll split the changes by their scope.

[Avasam]

@mhammond Concerning Redundant open modes (open("foo", "r") --> open("foo")) I can see preferring explicit open mode (because the default can change across language, so a reader/maintainer's expectation of "default" may differ if they don't explicitly remember python is r only by default) . Thoughts ?

---

Also, do you have a certain preference for using printf-style formatting? ("%s" %) over .format or f-strings? Because if not: https://docs.astral.sh/ruff/rules/printf-string-formatting/#why-is-this-bad

printf-style string formatting has a number of quirks, and leads to less readable code than using str.format calls or f-strings. In general, prefer the newer str.format and f-strings constructs over printf-style string formatting.

https://docs.astral.sh/ruff/rules/f-string/#why-is-this-bad

f-strings are more readable and generally preferred over str.format calls.

https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

Note The formatting operations described here exhibit a variety of quirks that lead to a number of common errors (such as failing to display tuples and dictionaries correctly). Using the newer formatted string literals, the str.format() interface, or template strings may help avoid these errors. Each of these alternatives provides their own trade-offs and benefits of simplicity, flexibility, and/or extensibility.

[mhammond]

@mhammond Concerning Redundant open modes (open("foo", "r") --> open("foo")) I can see preferring explicit open mode (because the default can change across language, so a reader/maintainer's expectation of "default" may differ if they don't explicitly remember python is r only by default) . Thoughts ?

I don't feel strongly about this, although I am perfectly fine with no mode arg - https://docs.python.org/3/tutorial/inputoutput.html explicitly says "The mode argument is optional; 'r' will be assumed if it’s omitted."

Also, do you have a certain preference for using printf-style formatting? ("%s" %) over .format or f-strings? Because if not: https://docs.astral.sh/ruff/rules/printf-string-formatting/#why-is-this-bad

Now we can assume they exist, I prefer f-strings. However, I'm not sure I prefer them enough to bother touching every string format in the tree.

[Avasam]

All changes categories have been extracted into their own PRs. They could be configured and enforced using Ruff, and automated using pre-commit.ci (#2034). I will close this as conversation about using modern standards can be moved to those PRs.