While we are circling this issue, it is worth noting that the substantial Hinsen rule breaking (or abandoning the original package name) changes being proposed are motivated due to a comparatively very tiny minority of users. And I'm saying this from that minority, as I work with CT data where we care about Hounsfield units.

The silent majority has been quite happy with "Anything in, anything out" for the lifetime of the package. Those - like myself - who need range preservation learn to use the helpful flags which are now available, or pre-convert our data to float with a known scaling so it can be recovered.

It's also worth considering that there is a substantial corpus of scikit-image teaching material out there. The majority we do not control, so cannot be updated or edited. The first hits on YouTube for tutorials are not the most recent, but older ones with lots of views. In virtually all cases, we tell users "anything in, anything out" and they will continue to hear and read this regardless of how strongly we might attempt to message around the change. As a result I expect the ongoing support burden will actually be worse with this change, than the low level support burden we've seen for years due to people not understanding datatype conversions.

So, I'll directly ask the question we're dancing around: Is it worth making preserve_range the default? As someone who would benefit from there changes, I am honestly no longer convinced it is. The workarounds for this problem are trivial from my standpoint as a user who does actually care about my data range, whereas the consequences of changing it at the package level are substantial and insidious - if not outright dangerous.

Josh

On Wed, Jul 21, 2021, 02:17 Riadh <rfezzani@gmail.com> wrote:

Hi,

Le 21/07/2021 à 03:27, Juan Nunez-Iglesias a écrit :

Riadh thinks, correct me if I’m wrong Riadh, that breaking it for 1.0 is ok, *especially* given the 0.20 warning. To be honest, one thing I like about the 0.20 warning is that it will *teach* people to pay attention to version numbers. The other plans, not so much. And these are important not just in this skimage transition but throughout the ecosystem. The Hinsen rule is broken dozens of times across the ecosystem. Even NumPy allows this over “long” deprecation periods. (See the copy=’never’ discussion.) But, back to summaries.

That's in fact my opinion :)

@Stefan, the copy='never' discussion is may be a bad example, but Hinsen himself cites Numpy as a reason for his code to collapse: "Today’s contributors and maintainers of the scientific Python infrastructure come from backgrounds with a much faster time scale of change. For them, NumPy is probably a sufficiently stable infrastructure, whereas for me it isn’t..."

Scikit-image depends on Numpy/Scipy that are already Hinsen-rule-breakers.

Back to our discussion, changing the package name or the import name will impact all our users, while only few of them are concerned with the Hinsen rule. Let's guide those ones to use virtual envs and version pinning that will definitely help them in developing reproducible research.
Riadh.
_______________________________________________
scikit-image mailing list -- scikit-image@python.org
To unsubscribe send an email to scikit-image-leave@python.org
https://mail.python.org/mailman3/lists/scikit-image.python.org/
Member address: silvertrumpet999@gmail.com