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
Once (#10) the target field is specified in a generalized way similarly to inits, the only field that will vary systematically between tasks will be inputs. In that case I suspect it will make more sense to eliminate subclassing of AbstractTaskTrialSpec, and instead define it as a generic final class, something like:
This would also save developers from explicitly including the intervene field in subclasses of AbstractTaskTrialSpec, because subclassing would be unnecessary; see #20.
I am still not sure how (if at all) to explicitly associate the structure of a given type of inputs, and the type of model that is compatible with a task. In principle, it could involve multiple fields of TaskTrialSpec; see #14.
The text was updated successfully, but these errors were encountered:
Currently, typing in
feedbax.task
is a mess. A source of this mess isAbstractTaskTrialSpec
.feedbax/feedbax/task.py
Lines 150 to 167 in 1c239e6
Once (#10) the
target
field is specified in a generalized way similarly toinits
, the only field that will vary systematically between tasks will beinputs
. In that case I suspect it will make more sense to eliminate subclassing ofAbstractTaskTrialSpec
, and instead define it as a generic final class, something like:This would also save developers from explicitly including the
intervene
field in subclasses ofAbstractTaskTrialSpec
, because subclassing would be unnecessary; see #20.I am still not sure how (if at all) to explicitly associate the structure of a given type of
inputs
, and the type of model that is compatible with a task. In principle, it could involve multiple fields ofTaskTrialSpec
; see #14.The text was updated successfully, but these errors were encountered: