Support typing

Describe the workflow you want to enable

Support Python typing, which is available in Python 3.5+, compatible with scikit-learn. This can enable tools to automatically get the estimator arg types (e.g., linters), for example. And it’s a Python standard now.

Describe your proposed solution

For example, SVC could be like this:

def __init__(
    self,
     C: float = 1.0,
     kernel: Union[Callable[[np.ndarray, np.ndarray], np.ndarray],
                   Literal["linear", "poly", "rbf", "sigmoid", "precomputed"]] = "rbf",
     degree: int = 3,
     gamma: Union[float, Literal["scale", "auto"]] = "scale",
     coef0: float = 0.0,
     shrinking: bool = True,
     probability: bool = False,
     tol: float = 1e-3,
     cache_size: int = 200,
     class_weight: Optional[Union[Mapping[int, float], Literal["balanced"]]] = None,
     verbose: bool = False,
     max_iter: int = -1,
     decision_function_shape: Literal["ovo", "ovr"] = "ovr",
     break_ties: bool = False,
     random_state: Optional[Union[int, RandomState]] = None,
 ) -> None:

Describe alternatives you’ve considered, if relevant

An alternative is to keep the types just in the docstrings. However, is hard for tools to parse the arg types.

[rth]

The value of introducing types seems greatly reduced in existing code-bases with extensive testing like ours.

For scikit-learn itself yes, it’s unlikely that we would discover many bugs with typing. For downstream users though, code can, and is likely to be insufficiently tested (it’s hard to write tests for the ML training code). There typing could add a lot of value.

Say you have a third party notebook with some scikit-learn code. How can tell if it’s valid, short of running it? At least running mypy on it would give you some confidence that there are no major issues in terms of how different classes are used.

[thomasjpfan]

data-science-types is currently archive because numpy now has support for typing. If we want the “ArrayLike” we most likely need to make it “Any” and if a new enough version of numpy (and python) is installed, use numpy’s ArrayLike type.

That being said, we can add type hints to __init__ for vectorizers without needing “ArrayLike”. I recommend doing that before looking at methods to gauge interest. Last time I tried to push for this in https://github.com/scikit-learn/scikit-learn/pull/17799 there was not much interest to merge. It could be different this time around.

In the meantime, I am thinking of releasing an independent “scikit-learn-stubs”, similar to what numpy-stubs did. With Protocols, all the ducktyping we do can be expressed nicely. scikit-learn-stubs would be a nicer packaged version of my sk_typing repo with proper tooling to make sure it is in sync, actual stub files, and following the style guide in typeshed.