-
Notifications
You must be signed in to change notification settings - Fork 59
Output vs Result #820
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
Comments
There is a |
but do we have good reason to hide it? |
I was just endeavouring to keep the namespace of the outputs object clear. Although I walked that back a little and added an |
but in general you believe, that |
I could be talked out of it, but I just thought it offers a slightly more convenient/less surprising introduction to Pydra if you get back a "namedtuple-like" outputs object rather than a results object. There is also the option of using the submitter explicitly if you want the result object. Sorry if this slipped through with all the other changes in my refactor. At this point it would be a bit of a pain to rewrite all the unittests back to handling Result objects, but not insurmountable |
@tclose - I've been working with pydra this week, and I was having problem on how to get
Result
object if the task is run in the simplest way as callable. Is it actually possible to get it or I'm able to get only theOutput
.This is what I am able to get:
So the second one gives full
Result
as expected, but the first only gives output that is equivalent toResult.Output
The problem with this is that we loose the access to many useful informations, e.g.,
cache_dir
,error
, etc.The text was updated successfully, but these errors were encountered: