Run pyupgrade 2.31.0.

[bdice]

This PR runs pyupgrade to modernize some syntax in the Python code base. (I am preparing a "better code" talk for our team that will reference this PR.)

The kinds of modernizing changes that pyupgrade makes are similar in purpose to those made by clang-tidy (#9860), but for Python. These include things like:

• Using literals for empty dicts {} and lists [], because they are a bit faster and more readable than dict() or list()
• Removing extra parentheses or braces wrapping generator expressions if not needed
• Preferring format strings
• Using canonical error names, e.g. IOError became an alias for OSError in Python 3.3.
• Replacing the "new-style" class definitions like class A(object): with the simpler syntax class A:
• Removing unnecessary __future__ imports that were needed for Python 2 compatibility, like print_function and division
• Using raw strings for regular expressions, to clarify intent and avoid extra escaping

The pyupgrade README has a long showcase of other rules.

Notes for reviewers:

• pyupgrade has a lot of opinions on how to use type annotations, and I'm not sure if I like all of them (some may have compatibility issues?). I have skipped over the type annotations for now, to set a more reasonable scope for this PR. See commit 54b16b9 (since reverted) for examples. Please let me know what you think about these changes and I may investigate them further in a follow-up PR!
• I have not added this tool to our CI style checks via a pre-commit hook yet. That can be done in a follow-up PR if we agree that we would like these types of changes to be required in the future.
• I used the argument --py37-plus to only perform changes that are compatible with Python 3.7+.
• I can revert the changes to the vendored code in versioneer.py if desired. (It's pretty outdated anyway, it looks like we're using versioneer 0.18, released on January 1, 2017.)

[codecov]

Codecov Report

Merging #10141 (8d33659) into branch-22.04 (a7d88cd) will increase coverage by 0.04%.
The diff coverage is 1.27%.

@@               Coverage Diff                @@
##           branch-22.04   #10141      +/-   ##
================================================
+ Coverage         10.42%   10.47%   +0.04%     
================================================
  Files               119      122       +3     
  Lines             20603    20500     -103     
================================================
- Hits               2148     2147       -1     
+ Misses            18455    18353     -102     

Impacted Files	Coverage Δ
python/cudf/cudf/_fuzz_testing/fuzzer.py	0.00% <0.00%> (ø)
python/cudf/cudf/_fuzz_testing/io.py	0.00% <0.00%> (ø)
python/cudf/cudf/_fuzz_testing/main.py	0.00% <0.00%> (ø)
python/cudf/cudf/_version.py	0.00% <0.00%> (ø)
python/cudf/cudf/comm/gpuarrow.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/_base_index.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/column/categorical.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/column/column.py	0.00% <0.00%> (ø)
python/cudf/cudf/core/column/datetime.py	0.00% <ø> (ø)
python/cudf/cudf/core/column/numerical.py	0.00% <0.00%> (ø)
... and 36 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0581975...8d33659. Read the comment docs.

[vyasr]

These changes look good to me. I made some comments, but in hindsight I think a significant chunk of them were in the versioneer files which I think we should just revert as you point out in your comment. No need to change vendored files. You should change the pre-commit hook to exclude those files when you do add it. I'm approving now because I suspect that once you remove the versioneer changes I only have 2-3 other comments and they're pretty trivial.

Regarding annotations, I like some of the changes but not all. Removing quoted types where possible is nice, but I don't really like using the pipe operator for or everywhere. I'm not sure what best practices are as far as using built-in types for annotations vs using their aliases from the typing module, I'd say let's see what some other projects do? But I definitely don't think we need to make these changes here

[bdice]

I think a significant chunk of them were in the versioneer files which I think we should just revert as you point out in your comment. [...] You should change the pre-commit hook to exclude those files when you do add it.

Reverted changes to versioneer. Yup, I'll exclude those files if we get to the point of adding a pre-commit hook for pyupgrade.

Regarding annotations, I like some of the changes but not all. Removing quoted types where possible is nice, but I don't really like using the pipe operator for or everywhere.

I agree, with your general sentiment -- pyupgrade's typing changes are the part I'm least sure about. (As an aside, I do agree with pyupgrade that replacing Union with T1 | T2 and Optional with T | None is just fine, or perhaps slightly better, because it lets you remove from typing import ... statements.) The use of annotations-as-strings vs. annotations-as-objects was discussed extensively in light of some recent PEPs and changes to Python 3.10 (see this issue from pydantic, for example). I'm generally uninformed about typing at this level of detail, but I think that typing behavior varies significantly among recent Python versions so I am taking an approach of "if it ain't broke... don't fix it." Is having mypy pass our only requirement for typing support?

I'm not sure what best practices are as far as using built-in types for annotations vs using their aliases from the typing module, [...]

The best practice is probably to use the built-in dict / list. See StackOverflow answer quoted below:

If you are using Python 3.7 or newer, you can use dict as a generic type if you start your module with from __future__ import annotations, and as of Python 3.9, dict (as well as other standard containers) supports being used as generic type even without that directive.

[bdice]

@gpucibot merge