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

[engelbert g. <eng...@gm...>]

no objection

On Fri, 16 Aug 2024 at 11:15, Guenter Milde via Docutils-develop <
doc...@li...> wrote:

> 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
>
>
>
>
> _______________________________________________
> Docutils-develop mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-develop
>
> Please use "Reply All" to reply to the list.
>