-
Notifications
You must be signed in to change notification settings - Fork 22
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
Remove deprecated arguments from SN model initialisers #356
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good so far, and we're heading towards a cleaner and more beautiful future interface!
Looks like you've got everything, concerning with legacy_filename_initialization
.
I agree with the plan to remove the deprecated parameters and putting them directly into the metadata.
Ready for review now! |
Oh, the integration tests are failing slightly earlier now; I’ll put in a fix for that in a minute … |
Okay, now the integration tests are back to failing in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes are mostly removal of unused packages, options, and legacy interfaces. Looks good.
This PR is intended to remove deprecations in the SN model initialisers, including initialising from a file name and inconsistent keyword arguments.
There are still a couple of
@deprecated
decorators we should remove before merging this. (E.g. for many models, theeos
keyword is marked as deprecated, because there is only a single possible value; so it shouldn’t be required as part of the__init__
.)I think the best way to proceed there would be to remove
eos
from the parameter list and manually setself.metadata["eos"]
in the__init__
to the fixed value instead. I’ll do that tomorrow and mark this as a draft PR until then; but wanted to get it out now before I go to bed, in case you want to review this during your daytime, @Sheshuk. (Yay for timezones! 😉)(Also: Yes, I’ve currently marked the branch from #353 as a base for this PR for simplicity; but can rebase it onto the
release_v2.0
branch tomorrow.)