Our pyproject.toml file, which we use for linting, contains several helpful error-checking rules, all of which have been manually disabled.

Rationale

Better parity with C++ error-checking

Some of these rules naturally correspond with clang-tidy or eslint rules that we already enforce such as:

reportPossiblyUnboundVariable and -Wuninitialized (transitively included by -Wall)
reportConstantRedefinition and -Wcast-qual
reportIncompatibleMethodOverride and -Woverloaded-virtual
reportUnusedExpression and -Wno-unused-parameter

Increase safety, improve developer productivity, and locate dormant errors

Having stronger error checks in our pyproject.toml not only will catch and report errors at linting-time, but also while writing code, as most Python LSPs will look for a pyproject.toml file and use it to generate inline diagnostics.

Switching all of these "none" s to "error" and running bazel run lint --all discovered 3503 errors. Many of these are likely false positives that could be easily addressed, but others could be genuine gaps in our testing code. For example, Pyright will report of the five (technically six, but two get combined into one) problems with the two functions below, and this code actually compiles and exits successfully.

def test_quadratic(a: float, b: float, c: float, expectation = float|int) -> bool:
    if isinstance(expectation, int):
        return test_quadratic(a, b, c, expectaiton=float(expectation))
    if b ** 2 - 4 * a * c < 0:
        raise
        ValueError("Invalid discriminant")
    root1, root2 = ((-b - (b ** 2 - 4 * a * c) ** 0.5)) / (2 * a), ((-b + (b ** 2 - 4 * a * c) ** 0.5)) / (2 * a)
    if root1 == root2 == expectation:
        return
    else:
        return print(root1, root2) and expectation in root1, root2

def test_quintic(): NotImplemented
  
assert test_quadratic(1., 0., -100., 10) 

Possible Adoption Avenues

3503 errors is unfeasible to address with one PR, so there are a few ways the work could be divided into multiple tickets:

1) Trivial vs non-trivial

Some rules can be enabled at no extra cost, since we already are not breaking them. See: SERVER-124516

2) Mechanical vs non-mechanical

Some rules require changes that are largely mechanical, and can be addressed by an LLM (or even by creating a short script that automatically generates the necessary changes based on the output of the lint command), and verifying correctness simply requires a short glance over the changes and ensuring that the lint command succeeds.

3) By Team/Directory

For the remaining rules, the lint command could be extended to support (if it does not already support) linting specific directories, and each team could then be responsible for driving their owned directories to zero warnings before we enable the corresponding rules globally. This lets us roll the change out incrementally (e.g., opt-in per directory or per team), avoid blocking unrelated work, and ensure that any necessary # pyright: ignore[...] or configuration exceptions live close to the code that needs them.