Ruff format

[kellerza]

Summary

Use ruff formatting to replace black & pylint

The files of interest in this PR is:

• pyproject.toml
• .pre-commit-config.yaml
• .github/workflows/python-app.yml

All other changes are as a result of ruff formatting

Future enhancements

There are several ignored ruff rules that require explicit changes in the code. Rules that should probably not be ignored are documented with comments in pyproject.toml.

# Comments next to codes explain why they are ignored
# All these are subject to review and possible removal in the future
lint.ignore = [
  "B007",    # Loop control var not used in the loop body
  "B008",    #Do not perform function call in argument defaults; instead, perform the call within the function
  "B020",    # Loop control variable `self` overrides iterable it iterates
  "B904",    # Within an `except` clause, raise exceptions with `raise ... from err` or `raise ... from None`
  "D203",
  "D213",
  "E203",
  "E501",
  "PLC0415", # `import` should be at the top-level of a file
  "PLE0307", # `__str__` does not return `str`
  "PLR1714", # merge multiple comparisons
  "PLR2004", # Magic value used in comparison, consider replacing `2` with a constant variable
  "PLW1641", # Object does not implement `__hash__` method
  "PLW2901", # `for` loop variable `value` overwritten by assignment target
]

Copilot overview

This pull request makes several improvements to the codebase and project configuration, focusing on simplifying and standardizing code formatting and linting tools, as well as modernizing string formatting and improving code readability in the authentication examples. The most significant changes are the replacement of black and pylint with ruff for formatting and linting, and the consistent use of f-strings and compact code in example scripts.

Tooling and CI/CD improvements:

• Replaced black and pylint with ruff for both linting and formatting in CI workflows (.github/workflows/python-app.yml), pre-commit hooks (.pre-commit-config.yaml), and documentation (CONTRIBUTING.md). Removed .isort.cfg as sorting is now handled by ruff. [1] [2] [3] [4] [5]

Code modernization and readability:

• Updated all authentication and directory example scripts to use f-strings for string interpolation instead of .format(), improving readability and consistency. [1] [2] [3] [4] [5] [6] [7]
• Reformatted example code to use more compact and readable expressions, such as single-line client initializations and function calls. [1] [2] [3] [4] [5] [6]

Docstring and style cleanup:

• Standardized docstrings in example scripts to be single-line where appropriate, reducing unnecessary line breaks and improving clarity. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

Minor code improvements:

• Removed unnecessary parameters (such as "r" in open calls when the default is sufficient) and simplified function arguments for clarity. [1] [2]

These changes collectively modernize the codebase, improve developer experience, and ensure consistency across tooling and code examples.

[kellerza]

The main reason to replace these tools is speed (gained from using rust-based tools like uv & ruff) and wanting to introduce more consistent typing (next PR)

[vgrem]

@kellerza, thank you for these great enhancements and contributions!

Wanted to mention that there's also a separate branch (py3-migration) where the migration of library to Python 3.6+ has been conducted, which includes several related improvements:

• style: enable f-string enforcement (C0209)
• refactor: migrate type hints from comments to annotations
• migrate: clean up Python 2 compatibility code (remove super() arguments)
• migrate: clean up super() calls and remove legacy lint rule
• migrate: convert type comments to inline annotations for booking namespace
• chore(linting): remove Python 2 rules and add Black config

…along with a few other things_

My main concern is that if both branches continue to evolve separately (with similar Python 3 migration changes), merging them could become quite challenging down the road.

I propose we merge this PR (and others?) into the py3-migration branch first. Then complete (including testing) we could finally merge the consolidated migration into main for release.

This approach keeps all the modernization changes together and minimizes merge complexity. What are your thoughts on this plan?

[kellerza]

In that case this PR might not make sense.

In the end I'd like to see:

1. modern uv as package/build system
2. ruff for linting + formatting (no more black/pylint...it's very slow)
3. full typing coverage with either mypy/pyright as part of pre-commit&github-action (I see type hints have already been migrated in py3-migrations)

What is the timeline to merge the py3-migration branch?

I don't mid re-doing step 2 above after the merge, or even on the py3-migrations branch

[vgrem]

Great, thanks for your flexibility. I appreciate you're willing to re-apply those improvements after the migration.

We're not in a hurry, would aiming to merge the py3-migration branch within the next week or two work for you?

[kellerza]

I'm ok with that timeline. Do you want me to apply step2 on the py3-migration branch so long, or rather wait till after the merge?

[vgrem]

Yes, please feel free to apply step 2 (ruff, etc.) directly to the py3-migration branch. That would actually be very helpful and would get those improvements integrated right away.

If you happen to spot anything else that could use cleanup or modernization, feel free to flag it or make changes. The more eyes, the better! :)