colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only)

[511bdf1c-9d01-4e5a-ae37-298f30f5b94c]

BPO	29625
Nosy	@mdickinson

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['type-bug'] title = 'colorsys.rgb_to_hsv always returns saturation as 0 (python2.7 only)' updated_at = user = 'https://bugs.python.org/WillPittman' ``` bugs.python.org fields: ```python activity = actor = 'mark.dickinson' assignee = 'none' closed = True closed_date = closer = 'Will Pittman' components = [] creation = creator = 'Will Pittman' dependencies = [] files = [] hgrepos = [] issue_num = 29625 keywords = [] message_count = 5.0 messages = ['288380', '288381', '288383', '288386', '288472'] nosy_count = 2.0 nosy_names = ['mark.dickinson', 'Will Pittman'] pr_nums = [] priority = 'normal' resolution = None stage = 'resolved' status = 'closed' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue29625' versions = ['Python 2.7'] ```

[511bdf1c-9d01-4e5a-ae37-298f30f5b94c]

colorsys.rgb_to_hsv appears to be broken on python2.7.13 (on archlinux). Saturation is always reported as 0.

ex:

import colorsys
rgb_to_hsv( 127, 116, 18 )
>>> (0.16666666666666666, 0, 127)

[511bdf1c-9d01-4e5a-ae37-298f30f5b94c]

The bug appears to be caused by the difference in division symbols between python3 vs python2.

The issue appears to be resolved if you add the following line to the /usr/lib/python2.7.13/colorsys.py module (or if all arguments are converted to floats).

from __future__ import division

I noticed that this bug persists all the back to at least python2.7.10

[mdickinson]

The arguments to rgb_to_hsv are supposed to be floating-point numbers in the range 0.0 to 1.0. That's documented here: https://docs.python.org/2/library/colorsys.html

Coordinates in all of these color spaces are floating point values. In the YIQ space, the Y coordinate is between 0 and 1, but the I and Q coordinates can be positive or negative. In all other spaces, the coordinates are all between 0 and 1.

[511bdf1c-9d01-4e5a-ae37-298f30f5b94c]

oh, thank you very much and sorry for my negligence!

[mdickinson]

No problem. I did spend some time wondering whether rgb_to_hsv still gives the correct results if any of the inputs happens to be an integer (though still in the range [0, 1]). It looks as though it does, though.