Inconsistent Clipping in the colorsys Module

In the issue 102581 it was pointed out the inconsistent application of clipping rules within the colorsys module’s functions, which claims to operate within the [0, 1] range. This inconsistency could lead to confusion and unexpected behavior for users relying on the module.

To tackle this problem, I’m proposing two main changes. Firstly, I suggest implementing uniform clipping rules across all functions in the module. This means ensuring that all functions consistently adhere to the specified range of [0, 1]. By enforcing this consistency, we can provide users with a more reliable and predictable experience when working with colors.

Secondly, I propose introducing a new optional argument, “clip,” to the functions in the colorsys module. This argument would give users the choice of whether or not to enforce clipping on a per-call basis. This flexibility is crucial for accommodating the needs of different industries or specific use cases that require an unbounded RGB color space.

I have opened a draft PR to shows the changes that I proposed and be a base for the discussion, let me know what do you think about the solution

Isn’t colorsys on the list of standard library modules that are supposed to get deprecated soon? Or did I misremember?

It was considered for PEP 594 (“Removing dead batteries from the standard library”), but decided to be kept.

2 Likes

Since they module it is here to stay, giving the possibility to use unbound inputs in function would help to modernize it.