Describe the refactoring action
Right now, some methods use kwargs for all their parameters, e.g. the analyse text method on pipeline level has the following signature: def analyse_text(self, source: Union[Path, IO, str], **kwargs) -> dict:.
I understand that this is convenient as we have less code and more flexibility when passing the parameters from the outer functions to the actual python-api requests. However, this hides some of the functionality and makes it difficult for users to understand which parameters exist.
Therefore, I think that we should explicitly expose the most important parameters. To me, this is most important for the text analysis endpoints (analyse_text, analyse_html, analyse_texts, analyse_text_to_cas). I would like to expose at least language and annotation_types, but probably also the timeout parameter.
Expected benefit
Users can better understand which parameters exist.
Describe the refactoring action Right now, some methods use kwargs for all their parameters, e.g. the analyse text method on pipeline level has the following signature:
def analyse_text(self, source: Union[Path, IO, str], **kwargs) -> dict:.I understand that this is convenient as we have less code and more flexibility when passing the parameters from the outer functions to the actual python-api requests. However, this hides some of the functionality and makes it difficult for users to understand which parameters exist.
Therefore, I think that we should explicitly expose the most important parameters. To me, this is most important for the text analysis endpoints (
analyse_text,analyse_html,analyse_texts,analyse_text_to_cas). I would like to expose at leastlanguageandannotation_types, but probably also thetimeoutparameter.Expected benefit Users can better understand which parameters exist.