I want to strongly suggest against having two branches. That said, the LTS release really took a lot of maintenance power, and involved a similar "feature/bugfix" parity. Do i understand that "strict deprecation" is something like what we have been doing already? On Wed, Mar 4, 2020 at 8:00 PM Stefan van der Walt <stefanv@berkeley.edu> wrote:
On Wed, Mar 4, 2020, at 15:01, Juan Nunez-Iglesias wrote:
I might not be getting the full picture here: returning Bunches instead of (in most places) NumPy arrays would in itself be a breaking change? Similarly, one of the big changes we are proposing is returning an array of floats that is *not* rescaled to [0, 1]. That is, we want to still return a NumPy array (whether that is the plain array or an attribute in the Bunch) but the values in the array will be different. I don’t clearly see how Bunch solves that problem?
There are at least two considerations here:
- We want to stop coercing image data to a certain range based on the data type of the input. This will be a breaking change, overall, unless we introduce the `preserve_range` keyword widely.
- We would like to make, consistently, most functions be of the form:
output_image = function(input_image)
This makes for easy construction of pipelines:
output_image = first_func(second_func(third_func(intput_image))
In cases where additional calculations are made, we want signatures of the form:
output_image, additional_namedtuple = function.extra(input_image)
[Exactly how the calculation of additional_namedtuple is triggered is not set in stone; the `.extra` attribute on functions was one suggestion of how to do that easily.]
The usage of named tuples / bunches / data objects will be an integral part of the design.
Best regards, Stéfan _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org