Adding type annotations

[fivesixzero]

This should address #31 and generally make the code easier to work with now. :)

[fivesixzero]

This buffer being declared as None but then getting used later in gesture() is a bit weird but understandable. Definitely causes a headache for some more aggressive linter configs though.

Not allocating it saves a decent chunk of memory but maybe there's a better way to handle it, like a gesture_enabled flag? Outside the scope here but maybe worth raising an issue for if you guys think its worth improving.

[fivesixzero]

I'm not sure where these are used, so it was hard to infer the types expected for args here. There's definitely a lot of floating point math going on so it seemed logical to keep the return a float.

The functionality here also might be duplicated elsewhere or out of scope for the library if it isn't making use of it internally.

[FoamyGuy]

I think the types used for r, g, and b here should match the types returned inside the tuple from color_data up here: https://github.com/fivesixzero/Adafruit_CircuitPython_APDS9960/blob/2c5ee6a3a6453bac2217f3db9a70bb83f022d961/adafruit_apds9960/apds9960.py#L351

This line in one of the example scripts passes those individual values from that tuple into calculate_color_temperature() here: https://github.com/fivesixzero/Adafruit_CircuitPython_APDS9960/blob/2c5ee6a3a6453bac2217f3db9a70bb83f022d961/examples/apds9960_color_simpletest.py#L28

However I'm not certain whether that type would be int or float. I would need to hook up a sensor and look at the values it returns to know for sure. I think maybe this sensor is used on the CLUE or perhaps Feather Sense. I'll try to see if I have one and check the value types.

[fivesixzero]

@FoamyGuy - Thanks for the review. :)

It makes total sense that the utility bundled here should operate on the same types that the library itself returns.

In the follow-up commit I changed the param types to int but kept the return float since we're doing some floating point math internally. If the caller wants an int it should be an easy conversion, I guess?

Changing it to int (and converting at return) would align it with the library as a whole though, at the small cost of potentially losing some (maybe not even required) precision in the output.

[fivesixzero]

I'm pretty sure the color data returned is an int. The data is retrieved by grabbing 16-bit chunks of a register though, which feels a bit excesive for a simple int. I'll double-check this behavior (and the datasheet) today and test it on a Feather Sense and/or a Clue for good measure

[fivesixzero]

Confirmed that the library indeed returns Tuple[int, int, int, int] in the current version of the code running on both a Clue and a Feather Bluefruit Sense.

Adafruit CircuitPython 7.1.0-beta.0 on 2021-11-12; Adafruit CLUE nRF52840 Express with nRF52840
>>> import board
>>> from adafruit_apds9960.apds9960 import APDS9960
>>> apds = APDS9960(board.I2C())
>>>
>>> color = apds.color_data
>>>
>>> type(color)
<class 'tuple'>
>>> len(color)
4
>>> type(color[0])
<class 'int'>
>>> type(color[1])
<class 'int'>
>>> type(color[2])
<class 'int'>
>>> type(color[3])
<class 'int'>

So we're good there. :)

[FoamyGuy]

changes look good to me. I successfully tested the simpletest example on a CLUE with 7.0.0 release version and verified the types shown in PyCharm IDE.