[Nipy-devel] [nipype] traited branch

Christopher Burns cburns@berkeley....
Thu Jan 14 01:14:11 CST 2010


On Wed, Jan 13, 2010 at 7:21 PM, Dav Clark <davclark@berkeley.edu> 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']
    if self.inputs.A:
        b_trait.set_metadata('mandatory', True)
    else:
        b_trait.set_metadata('mandatory', False)

Currently the check_mandatory_inputs function only checks if the trait
has a 'mandatory' metadata element, it could easily check if it's True
instead.

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
another name.

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.

Chris



More information about the Nipy-devel mailing list