-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add type hinting #192
base: master
Are you sure you want to change the base?
Add type hinting #192
Conversation
The most useful place to have type hints is annotations for variables that are only defined in the yaml (so consistency can then be checked just using standard editors like vs code/Pycharm). In many places types can be inferred accurately, and little to be gained by adding them explicitly unless useful for doc of public interface. Note: want to make sure you don't statically import anything that's an optional dependence (e.g. ccl). |
I added checks for the quantities from yaml files, which now must match the expected types. Let me know what you think of the current strategy. For the explicit typing in the code, I am a fan of a bit of redundancy in this case, but it is just a matter of taste. I think it makes the code more readable as the user knows, at first sight, what type a certain quantity is. Still, I am planning to go through the modifications and clean the code, because some may be too obvious. |
There's a CobayaComponent-level method intended for parameter validation, validate_info (https://github.com/CobayaSampler/cobaya/blob/master/cobaya/component.py#L415). You could override this in one of SOLikeT's base classes to check that all assignments match the types in the annotations. (It shouldn't really be necessary to repeat the type once defined in the attribute's annotation). But perhaps better would be to add a general "_enforces_types" class attribute to Cobaya, and add code to Cobaya's Component.validate_info to fully validate types for any descendant class that sets _enforce_types is True.
[Note I am travelling most of the next two weeks, so likely not responding to any Cobaya issues] |
Starting from the code you suggested, I refactored the type-checking functions to avoid repeating the types. Also, now they accept essentially all types, including nested ones (e.g. List[str], Dict[str, float], Tuple[str, str, int], etc). As a testing ground, I used the |
This is the first attempt to add type hinting throughout the repo, mentioned in #189.
I was quite generic on many occasions as this is just supposed to give us a place to work on this and can be refined once we agree on some strategy.