[Docutils-develop] Type hints for readers, parsers, writers overly verbose.

[Guenter M. <mi...@us...>]

Dear Adam, dear Docutils developers,

Commits [r9872], [r9873], and [r9874] added type hints for the
"readers", "parsers", and "writers" modules increasing their size by
42, 70, and 112 lines respectively.


The reason is the provision of the exact output value for a set of specific
input vales via the `@overload` decorator for the auxiliary functions
`get_*_class()`.

IMO, this is an overkill: the `@overload` is fine, if different types of
input values result in different types of output values, e.g,

    def foo(a: str) -> str
    
    def foo(a: binary) -> binary

but not for individual values of the same type that return a class that is
a subclass of a well defined abstract base class (readers.Reader,
parsers.Parser, writers.Writer) and where the set of admissible values is
not known (any 3rd party component is found, too).

My argument is, that the `get_*_class()` function is intended for use
when the component class is fetched at runtime from user configuration 
(which means we only know that the return value conforms to the interface
of the abstract base class).

In cases where a statical type checker knows the `reader_name`,
`parser_name`, `writer_name` (and this matters) there is no need to use
`get_*_class()` but the calling code may directly import the component
class.

Unless there is a convincing use case, I vote for reversal of the change to
the `get_*_class()` functions. However, I'd like some feedback before
actually reverting.

Günter