Increase robustness of the code

[lionelkusch]

I find three ways to increase the robustness of the code:

1. Add assertion at the beginning and at then end of functions:
   This can help to debug the code and the assertion can be remove with the option -O or -OO of python.
   The only inconvenient, at this option is that the user need to know the existence of this option of python.

2. Add type to argument of functions:
   There is some recommendation here.
   I don't really like this way because types in python become less readable.

3. Choose only critical test to do and raise the associate error (see Policy for testing types of input parameters #61).

[lionelkusch]

@Remi-Gau @bthirion @man-shu
What is your opinion on it?

[Remi-Gau]

Personal preference for defensive programing that raise actual error for wrong inputs rather than "just" assertion.

Though having assertion is better than nothing.

Checking types of type of outputs I would delegate to actual tests so you don't bother with it at run time.

Am a big fan of type annotation that can defo help catch some bugs or some issues but I won't press the issue as I believe you can do a lot of what you need here without them.

[lionelkusch]

I am sorry, I made confusion between three mechanisms for raising errors.

• Assertions: These are used to verify the correctness of the API and facilitate debugging.
• Types: These are used for static type checking, ensuring consistent usage of the API.
• Exceptions: These inform users of any issues or unsupported usage.

In reality, these three methods can overlap and may even be used concurrently.
I don't know what the good balance is between getting a very robust library and saving time to debug and the time spent including all these assertions, these types and these exceptions.

[bthirion]

To me exceptions are more useful than assertions, but this is no more than a feeling.

[Remi-Gau]

I am fine starting with assertions and then slowly turn those into proper exceptions.

Type annotation: users may benefit from those especially for the type of return values of public functions / methods: makes auto-complete of several IDEs much more accurate.

[lionelkusch]

I made an example of it.
For the type, I didn't get an error with mypy. I added this syntax checker as a dependency, which can be included in the GitHub action later on ( it can be complementary to pytest using the package with pytest-mypy). However, I am not sure that my types are the best ones, I think there can be more restrictions or to be defined in a different way.

For the assertion, there are not here only for the type but for more checks, size of the array, type of data, .... From my point of view, their main advantage is that they can be deactivated.
I didn't find, for the moment, an interesting error to report for ada_svr but I agree some assertions can be transformed into an error at some point.

[lionelkusch]

This is a return from experience of a project including types in ProgressiVis: https://sed.saclay.inria.fr/demandez-le-programme/presentations/2023-06-27.pdf

[lionelkusch]

You should look if it's interesting to include SonarQube in the CI.