[Nipy-devel] [nipype] traited branch
Thu Jan 14 01:14:11 CST 2010
On Wed, Jan 13, 2010 at 7:21 PM, Dav Clark <firstname.lastname@example.org> wrote:
> In any case, the reality is that the mandatory constraints on a a set
> of inputs might vary given the settings of some other inputs. The
> simplest example I can think of would be as with Fnirt, where you can
> specify a warpfield or a coefficient file. It's not that either of
> those are mandatory, but in some cases, it is mandatory that one or
> the other (but not both) are set.
> That said, such logic is not managed via call-signature convention
> either - so we need a solution to this in any case.
> We'd need to capture a set of entailments something like:
> 1) If input A is True, then input B must be set
> 2) (Only) one of inputs A, B, etc. must be set
> 3) If input A is True, then (something like 2)
We could have dependency relations stored as metadata also. And use
event handlers to toggle the mandatory flag. So in the case of #1
you'd have something like:
self.inputs.A = traits.Bool(argstr='-a')
self.inputs.B = traits.Bool(argstr='b', mandatory=False)
# event handler
def _A_changed(self, name, old, new):
b_trait = self.inputs.traits()['B']
Currently the check_mandatory_inputs function only checks if the trait
has a 'mandatory' metadata element, it could easily check if it's True
We could even had metadata that is a list, like depends_on=['A', 'B'].
Although traits.Property already uses 'depends_on' so we may need
I believe between the metadata features and the traits notifications,
we could handle this. If we decide to...
> But I'm wondering how
> much work is worth doing for interfaces? I mean - SPM, FSL and so on
> are going to check their inputs also and kick back an error message
> that we could capture and report.
Definitely worth keeping in mind. And on many fronts, including documentation.
> Don't worry! Things are currently worse than all this in the trunk,
> and that works well enough! At least now we'll have type-checking! ;)
"Always look on the bright side of life" (whistle along with me now...)
>> so are you and dav thinking of adding a metadata function to an input to
>> generate the output file name?
> I suggested that we could do something like this, but I think this is
> also a bit of a last resort.
I agree with Dav that the metadata function should be avoided if we
can find more simple solutions.
More information about the Nipy-devel