Type checker

[GiovanniCanali]

Fixes #440: add a type checker to be used for debugging.

If the debugging level is set to DEBUG, the enforce_type decorator will enforce the type hints both for the decorated function's arguments and return value.

It requires type hints in the decorated function.

Example:

import logging

# Set logging level to DEBUG
logging.getLogger().setLevel(logging.DEBUG)

@enforce_types
def dummy_function(a: int, b: float) -> float:
    return a+b

# This  works
dummy_function(a=1, b=2.0)

# This raises a TypeError for the second argument
dummy_function(a=1, b=3)

# This raises a TypeError for the second argument
dummy_function(a=1, b="Hello, world!")

[GiovanniCanali]

To me looks good the structure, I am only wondering if we should merge it as it is or making it draft, update all files where we want type checking and then merge

I share this doubt with you. As it is, this decorator is nice but cannot be used immediately, as we do not have any type suggestions in PINA. I see the following options:

• We add type suggestions for all functions in the package, in order to be able to use the decorator whenever we need it.
• We add type suggestions for all functions in the package, and use the decorator instead of hard coded checks.
• We use the decorator only for code development. Once the code is ready and working, type checks are removed.

Of course, the second is an option only if the decorator is faster than hard coded checks, which I think might not be the case. The first one requires a lot of work, but I would be happy to contribute.

Let me know what you think about it, @dario-coscia!

[dario-coscia]

I

To me looks good the structure, I am only wondering if we should merge it as it is or making it draft, update all files where we want type checking and then merge

I share this doubt with you. As it is, this decorator is nice but cannot be used immediately, as we do not have any type suggestions in PINA. I see the following options:

• We add type suggestions for all functions in the package, in order to be able to use the decorator whenever we need it.
• We add type suggestions for all functions in the package, and use the decorator instead of hard coded checks.
• We use the decorator only for code development. Once the code is ready and working, type checks are removed.

Of course, the second is an option only if the decorator is faster than hard coded checks, which I think might not be the case. The first one requires a lot of work, but I would be happy to contribute.

Let me know what you think about it, @dario-coscia!

The type checker only checks types, but the check_consistency function can be made more versatile in the future. However, type checking in debugging is very useful; maybe we can use it as a type checker, for example:

Line <line> of file <file> ===>  Entered in function <function name>, with input <input name> and input type <input type>
                                         ===>  Entered in ....
                                         ===>  Entered in ....
Line <line> of file <file> ===>  Entered in function <function name>, with input <input name> and input type <input type>
                                         ===>  Entered in .... 

This way, it is by default turned off, but when debugging is enabled, it does the following. We can start thinking about adding it to the solver and see where it is also needed. Let's also listen to @ndem0 and @FilippoOlivo for this

[dario-coscia]

Maybe also related to #551 ? @GiovanniCanali what do you think?

[GiovanniCanali]

Maybe also related to #551 ? @GiovanniCanali what do you think?

Yes, definitively!