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
Some discussion is underway to clean up the Step methods including callrun and __call__ to clarify which methods create new instances, fetch reference files, overwrite parameters etc.
One currently discussed plan would be to:
deprecate (with a UserWarning or some other warning visible in notebook runs) __call__ for eventual removal, requiring the explicit use of run or call (or the renamed versions)
deprecate (again with a notebook visible warning) both run and call in favor of a less ambiguous name
I'd make an argument that part of the confusion is that call is a classmethod yet a user can call it on an instance. Replacing the classmethod with a separate function would help clean this up maybe create_and_run(step_class, ...) where the method can check that step_class is not an instance.
run could be renamed to maybe run_without_crds_parameters to make it explicit that the crds parameter files will be ignored.
I think deprecating __call__ is probably not a good idea, as that's generally what one does with class instances - calls them. I think what __call__ points to, i.e. self.run is problematic, but only because the class constructor doesn't take (generally) input data as a required input.
Agree completely that Step.call is a class factory and should be a function, not a class method. It is confusing to users to allow it on an instance. I would not be for adding more non-pythonic methods of creating steps and running them. Keep it as one would expect it to be in Python.
Those are just some inital thoughts. Not new by any means, but things we knew were bad 6 years ago.
xlinking spacetelescope/jwst#8130
Some discussion is underway to clean up the
Step
methods includingcall
run
and__call__
to clarify which methods create new instances, fetch reference files, overwrite parameters etc.One currently discussed plan would be to:
UserWarning
or some other warning visible in notebook runs)__call__
for eventual removal, requiring the explicit use ofrun
orcall
(or the renamed versions)run
andcall
in favor of a less ambiguous nameI'd make an argument that part of the confusion is that
call
is aclassmethod
yet a user can call it on an instance. Replacing theclassmethod
with a separate function would help clean this up maybecreate_and_run(step_class, ...)
where the method can check thatstep_class
is not an instance.run
could be renamed to mayberun_without_crds_parameters
to make it explicit that the crds parameter files will be ignored.Pinging @jdavies-st for comments.
The text was updated successfully, but these errors were encountered: