Use of str(type(object)) causes lock up on Tufty 2350 v.1.0.0.0

[bouncingboffin]

In MicroPython I am trying to create an XOR plotting routine and was comparing two color objects but couldn't get that to work, so I tried to view the contents of the color object:

`clockForeground = color.rgb(255, 255, 0) # foreground is yellow

temp = str(type(clockForeground))`

I couldn't get anything to come out, then removed the I/O but it still crashes when str() is used on the type() function.

[Gadgetoid]

Sorry this got a little lost in the docs repo. It's possible we fixed this in version 2.x.x of the Badgeware firmware since an attempt to recreate it seemed to work as expected:

>>> clockForeground = color.rgb(255, 255, 0) 
>>> str(type(clockForeground))
"<class 'color'>"

(We might have had a vestigial "print" function defined for color which was pruned in the update.)

At the moment the == operator isn't implemented for a color object, so they are incomparable and will always compare False. eg:

>>> color.rgb(0, 0, 0) == color.rgb(0, 0, 0)
False

A really ugly workaround for that is to access the raw premultiplied colour value and compare that instead. eg:

>>> color.rgb(0, 0, 0).p == color.rgb(0, 0, 0).p
True

Which also lets you explore how colours are stored internally:

hex(color.rgb(0, 0, 0, 255).p & 0xffffffff)
'0xff000000'

And experience first hand why we're currently hiding colour values somewhat:

>>> hex(color.rgb(255, 255, 255, 0).p & 0xffffffff)
'0x0'

You would perhaps expect the above to return 0x00ffffff because you asked for 255, 255, 255 with 0 alpha, but for drawing performance we "pre multiply" the individual colour channels with the alpha value and effectively destroy the original colour information.