Skip to content
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

Input / output validation for calcfunctions and workfunctions #3569

Closed
greschd opened this issue Nov 25, 2019 · 5 comments · Fixed by #5900
Closed

Input / output validation for calcfunctions and workfunctions #3569

greschd opened this issue Nov 25, 2019 · 5 comments · Fixed by #5900

Comments

@greschd
Copy link
Member

greschd commented Nov 25, 2019

Since we're dropping py2 support in #3566, we can make use of glorious new features.

One possibility would be to add (optional) input / output validation for calcfunctions and workfunctions through type hints.

Example:

from aiida import orm
from aiida.engine import calcfunction

@calcfunction
def add(x: orm.Float, y: orm.Float) -> orm.Float:
    return x + y

Should be quite straightforward to implement. Opinions on whether this would be desirable?

@chrisjsewell
Copy link
Member

+1 from me

to elaborate on the implementation (copied from #3724):

From python 3.6 onward I believe, type annotations are stored in __annotations__, e.g.

@calcfunction
def my_calcfunction(structure: StructureData):
    pass

my_calcfunction.__annotations__ == {"structure": StructureData}

This could be used here, to set a more specific valid_type than just orm.Data:

spec.input(arg, valid_type=valid_type, default=default)

@greschd
Copy link
Member Author

greschd commented Jan 23, 2020

Just checked on 3.5, works there as well. The output annotation is stored in the 'return' key (since that's a keyword, it can't be an input name).

@chrisjsewell
Copy link
Member

chrisjsewell commented Jan 23, 2020

If you wanted to get really fancy, you could also use TypedDicts, to set output validation on multiple outputs, but that's only available natively from python 3.8

@greschd
Copy link
Member Author

greschd commented Jan 23, 2020

I guess the user can always specify that as return value, and we just need to make sure it works out with the isinstance check, right? If some user code only supports 3.8+, that shouldn't bother us.

@ltalirz
Copy link
Member

ltalirz commented Sep 10, 2020

Just mentioning that we will drop python 3.5 support with the next release , following the compatibility timeline

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants