-
Notifications
You must be signed in to change notification settings - Fork 3
Description
The auto
value can be used for a few different parameters of different methods, such as:
axis
of a dezinger method wrapped byDezingingWrapper
httomo/httomo/method_wrappers/dezinging.py
Lines 51 to 58 in 74b94c9
if "axis" in self.parameters: args = self._build_kwargs( self._transform_params(self._config_params), block ) # plug in the correct value for axis instead of auto. In case if axis is absent we # take it equal to 0. This is to avoid failure, but (missing) template parameters # should be tested in the yaml checker potentially self._config_params["axis"] = args.get("axis", 0) axis
of an image saver method (though doesn't appear in the image saver wrapper, but in the generic wrapper)
httomo/httomo/method_wrappers/generic.py
Lines 264 to 269 in 74b94c9
elif ( p == "axis" and p in remaining_dict_params and remaining_dict_params[p] == "auto" ): ret[p] = self.pattern.value
The underlying methods from their respective libraries have the axis
parameter which don't have auto
as a possible value, but in httomo YAML pipeline config files we have introduced the ability to override the value of this axis
parameter and have the associated wrapper transform the "auto"
into something else on behalf of the users.
This results in the YAML config file for a method using the auto
value presenting a different public API compared to the public API of the method function in its respective library (ie, its type signature): in httomo, the value of axis
is presented to be able to be auto
, but in the method function itself, the value of axis
is an int
. These will have different types:
- allowing
axis
to have a value ofauto
in addition to integers will have the typeUnion[Literal["auto"], int]
- allowing
axis
to only have an integer value will have typeint
The method wrappers doing this transformation from auto
to an int
(which form the perspective of types is a conversion from a Union[Literal["auto"], int]
to an int
) aren't documented as doing so.
Documenting the method wrappers to at least have some information about the transformation being done can help mitigate confusion regarding the two conflicting public API's that are exposed by httomo's YAML config files vs. the method function's documentation.