-
Notifications
You must be signed in to change notification settings - Fork 2
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
Literal["pickle"] type annotation #574
Comments
So first, at a high level, you get no disagreement from me. I prefer to avoid strings, and I find your For some context, you're right that the string options like this do tend to appear regularly in python code. In our more specific community, there is a "pyironic" aversion to imports. Both The fact we have the argument at all is a backwards-compatibility step to an earlier period when there was indeed more options ("h5io"). So, for now, if we're going to make any changes I would propose to simply accept |
I think I have to change my opinion about |
BTW |
Let's see if I can make |
Tada
We should enable more checks :) Do not compare apples with oranges. |
Regarding the
Literal["pickle"]
type hint here:pyiron_workflow/pyiron_workflow/storage.py
Lines 281 to 318 in a3d38f7
I know it is quite common in Python modules to have arguments like
backend
ormethod
of type string to select what to do. However, I think a solution like this is much better:mypy
can catch non-exhaustive match cases or if-else cascades, aka I forgot to add the new type there.Anyhow, I do not see why this function needs to be so complex in the first place. I think enforcing
node.save(PickleStorage())
and not allowingnode.save("pickle")
is reasonable. It also avoids the obscured initialization of thePickleStorage
. If we want to keep the interface, what aboutHowever, this requires
node.save(StorageInterfacesEnum.pickle)
The text was updated successfully, but these errors were encountered: