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 --> Prefer f-strings and non-printf-style format #2122
• https://github.com/asottile/pyupgrade#redundant-open-modes --> Redundant open modes #2121
• https://github.com/asottile/pyupgrade#unittest-deprecated-aliases --> adodbapi: Remove obsolete aliases #2088
• https://github.com/asottile/pyupgrade#oserror-aliases --> Update and standardise obsolete OSError aliases: #2107 & adodbapi: Remove obsolete aliases #2088
• https://github.com/asottile/pyupgrade#invalid-escape-sequences --> Fix invalid and accidental escape sequences #2112
• https://github.com/asottile/pyupgrade#super-calls --> Use modern "zero arguments" style for super #2106
• extraneous parens --> Remove extraneous parentheses found by Ruff/pyupgrade #2110
• https://github.com/asottile/pyupgrade#set-literals --> Update collection literals and comprehensions #2108 & adodbapi: Update collections literals and comprehensions #2109

[Avasam]

I know Scintilla is vendored, but these changes are automated. Just like pycln, isort and black, is that fine? I assume the idea is that we trust this won't lead to behaviour changes and that updating Scintilla won't cause these changes to be lost because they'll be automatically re-applied.

[mhammond]

The problem then will be that re-vendoring in the future would break, meaning we'd need to work out what to re-run etc. It seems better long term to just ignore scintilla entirely, which works both today and in the future.

[mhammond]

This has very marginal value IMO. pyupgrade describes itself as "A tool ... to automatically upgrade syntax for newer versions of the language." but it is clearly going way beyond that - it's also very opinionated about stylistic things and I'm not convinced we need yet another opinionated tool. Are any of these changes actually going to become syntax errors in later Python versions?

[mhammond]

The problem then will be that re-vendoring in the future would break, meaning we'd need to work out what to re-run etc. It seems better long term to just ignore scintilla entirely, which works both today and in the future.

[mhammond]

I'm quite surprised this tool is so opinionated about comments, but it got it wrong here - the existing "\\" should now be "\\\\"

[Avasam]

I don't think it's an opinion about comments: it correctly found (and fixed) an invalid escape sequence in the dosctring: \s. It didn't touch the existing \\ because that"s a valid \ character once escaped.

That being said, you're right this docstring should have \\\\machinename\\ to properly escape to \\machinename\ (or make the whole thing a raw docstring)

[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.