You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depending on the workflow you might get a dict, or a tuple of floats, or a tuple of dicts. In each individual case these make perfect sense, but overall the variance makes the Workflow class feel disjointed. What about enforcing consistency across return values, e.g. Workflow.analyse_structures(self, output_dict: dict) -> dict?
Advantages:
Workflow return values seem pretty clear in the code, e.g. return eng_pot, kinetic_energy, but this is lost to the user who just sees two floats and needs to go look at the docs to figure out their meaning; with a dict those nice variable names could be directly visible
It makes it easier to consistently leverage the workflows downstream; e.g. in pyiron_workflow we have a node to extract workflow results and it's named result_dict, but this is not true for some of the workflows even though the node is working perfectly fine.
Ideally one could even use something like a DotDict so the results are both named and tab completable.
The text was updated successfully, but these errors were encountered:
Depending on the workflow you might get a dict, or a tuple of floats, or a tuple of dicts. In each individual case these make perfect sense, but overall the variance makes the
Workflow
class feel disjointed. What about enforcing consistency across return values, e.g.Workflow.analyse_structures(self, output_dict: dict) -> dict
?Advantages:
pyiron_workflow
we have a node to extract workflow results and it's namedresult_dict
, but this is not true for some of the workflows even though the node is working perfectly fine.Ideally one could even use something like a
DotDict
so the results are both named and tab completable.The text was updated successfully, but these errors were encountered: