Skip to content

Type checker #527

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

Conversation

GiovanniCanali
Copy link
Collaborator

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 GiovanniCanali added enhancement New feature or request pr-to-review Label for PR that are ready to been reviewed labels Mar 27, 2025
@GiovanniCanali GiovanniCanali self-assigned this Mar 27, 2025
@GiovanniCanali GiovanniCanali force-pushed the type_check branch 3 times, most recently from 64a9f0a to 9ef2f45 Compare March 27, 2025 16:05
@GiovanniCanali GiovanniCanali linked an issue Mar 31, 2025 that may be closed by this pull request
Copy link
Collaborator

@dario-coscia dario-coscia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@GiovanniCanali
Copy link
Collaborator Author

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
Copy link
Collaborator

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 dario-coscia force-pushed the dev branch 2 times, most recently from a84b105 to a2b6c1f Compare April 14, 2025 09:44
@dario-coscia
Copy link
Collaborator

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

@GiovanniCanali
Copy link
Collaborator Author

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

Yes, definitively!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pr-to-review Label for PR that are ready to been reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Static type checking for debugging
3 participants