What does this PR do?

This PR introduces type-checking in CI. It uses Pyright. It adds failing tests at first, and we can decide in this PR whether we want to continue, which will involve a number of more PRs to resolve issues.

We previously discussed this at #2749. I have since gone away and tried Pyre and Pyright, and prepared lots of little changes locally.

Advantages of type annotations in code

• Hints while coding, so you need fewer keystrokes.

• Error checking while coding. This image is for the bug in Make Scores.__repr__ actually return something #2897
  

• Clearer code, since type annotations explain interfaces at a slightly higher level than the code itself does. SpeechBrain maintainers may have a high-level overview of the code which compensates, but people with smaller brains and not that familiar with SpeechBrain (e.g. me) will find type annotations more useful.

Disadvantages of type annotations in code

• More visual noise. From the earlier discussion, not everyone likes looking at : Union[float, int, None]. Though it turns out that from Python 3.10 (I used to think from 3.9), you can say : float | int | None. But note that docstrings currently already have type annotations; just not all correct or grammatical.

Advantages of type checking

• The type annotations are more likely to correspond to the actual code. There are many instances in the current code where type annotations are inconsistent, and therefore misleading. This especially goes for type annotations in docstrings. E.g. in a few places arguments have type enumerable in docstrings.
• Types of code that trip up the type checker also tend to trip up people. Again, maybe mostly small-brained people like me.

I have some experience with type checking in a serious Python project (https://github.com/apple/pfl-research), and have found it useful in making code correctly modular and clear to adopters.

Disadvantages of type checking

• False positives. In particular, a type checker cannot reason through dynamic aspects of PyTorch so spurious errors occur. Change nn.Module.__getattr__ return type to Any pytorch/pytorch#104321
• Errors for code that works but is not necessarily clear, to the type checker or to humans.

Why Pyright?

I started off using Pyre, but Pyright is better.

• Good integration in VS Code. The Pylance extension uses Pyright. Try it out! (You may need the pyproject.toml from this PR.)
• Faster. Roughly a second for a single file. Though at 10-30 seconds for the whole repo, not fast enough to run as pre-commit check, I think.
• Pyright is better at inferring type changes, for example "if f_max is None: f_max = 1".
• Clearer error messages.
• Errors can be ignored with type: ignore, which generalises to other type checkers.
• More consistent errors across set-ups / computers.
• Easier to switch off checks for files.
• It is possible to set which aspects are checked. This will e.g. allow us to switch on more checks, e.g. after errors are found that this check would have prevented.

Proposal for getting this in

1. See all errors (thousands) in the CI.
2. Me to put in multiple PRs to fix/silence errors. I've got the changes prepared locally.
3. Me to put in extra PRs for errors that I didn't get locally.
4. Once those PRs are all merged, merge this PR.
5. Reap the benefits of type-checking: correctness, and help while coding.
6. [Optionally] Run type checks for recipes/ too, and fix errors.
7. [Optionally] Move type annotations from docstrings into function signatures. This seems a good idea to me, so that type annotations can be checked. However, the pre-commit checks currently include a check that type annotations go in docstrings.

Types of changes that need to be made

I've got a branch locally which fixes all errors I am seeing locally on a six-month-old version of SpeechBrain. But I believe I understand what sorts of PRs I'll put in, in units that should be as easy as possible to review.

1. Around 15 small PRs where I'm fairly sure there's a bug and I can fix it. The first one is Make Scores.__repr__ actually return something #2897. I should put these in either way.
2. Around 20 cases where type annotations are wrong, in one big PR. I should put these in either way.
3. Around 30 cases where I believe there's a bug but I will need to check with people.
4. Around 100 cases where type annotations are needed to help the type checker, ass well as humans, in 1-3 PRs.
5. Around 60 cases where the type checker needs assumptions to be made explicit, in one big PR. The majority are of the form assert argument is not None. I would argue that these are useful to make explicit. Moreover, going forward I believe for code reviewers to see these sorts of explicit assumptions.
6. Around 50 cases where the type checker believes that a variable can be unbound. This will be one big PR. See below for an example. I find this style of code confusing, but the code usually seems correct. See below for an example.
7. Around 15 cases where overrides are not technically correct, which I imagine usually doesn't create a problem. This will be one big PR. See below for an example.
8. Around 50 cases (around 100-150 lines) where the code seems fine, though maybe not a style that I would have used, so we need to add # type: ignore (or a file-wide ignores in a few cases, like speechbrain/inference/ASR.py, which is quite dynamic). This will be a few PRs.

I can show any of these in a PR before the decision whether introducing type checking is a good idea.

Cases where an assumption needs to be made explicit

def function(bool use_joint, joint=None):
    if use_joint:
        assert joint is not None  # Needs to be added...
        joint(data ...)  # ... otherwise error: Object of type "None" cannot be called

In my mind, this would be good to add this for readability and understandability if the caller violates the contract.

a: Optional[int]
b: Optional[int]

if a is None and b is None:
    raise ValueError("...")

if a is None:
    # Assert must be added or type checker thinks that "b" could be None.
    assert b is not None
    c = b[1]  # Error: None is not subscriptable.

def function(bool return_two) -> int | Tuple[int, int]:
    if return_two:
        return 1, 2
    else:
        return 1

a, b = function(True)  # Error: "int" is not Iterable.
# Requires asserting that the return value is a tuple:
a, b = cast(tuple, function(True))

In this case, I would personally have preferred to use two separate functions for the separate types of return values.

Case where a variable looks possibly unbound to the type checker
E.g.

if condition:
    variable = 3

...

if condition:
    variable + 2  # Error: possibly unbound.

In this case, I say variable = None at the top and then assert variable is not None within the second condition.

Case where an override is not technically correct

Just one example of an error:

speechbrain/nnet/diffusion.py:252:9 - error: Method "distort" overrides class "Diffuser" in an incompatible manner
    Parameter 3 name mismatch: base parameter is named "timesteps", override parameter is named "noise" (reportIncompatibleMethodOverride)

I have assumed that in these cases, the code has been tested and runs correctly, i.e. no one calls the method with the base class's signature.

PR review