Cosmetic fixes, updated rainbow_cycle

[kattni]

No description provided.

[caternuson]

General comment as this applies to the entire file. This example was written before the ability to define pixel order in the constructor was added. See issue #1 and pr #24. Using bpp was the old way of doing it. This could all be re-written to remove use of bpp and change to using pixel_order in the constructor.

[kattni]

I totally forgot about that. You're right.

[caternuson]

Yep. Like that.

Now that format_tuple func is bugging me. I'm concerned it's going to be seen as some necessary magic that users will propagate into their own code.

1. Remove format_tuple
2. Change wheel to check ORDER, i.e. move the logic from format_tuple to wheel
3. Change the pixels.fill() lines in the loop to just call with a tuple, and have conditionals to check ORDER to call with a 3 tuple or 4 tuple as needed. That way the pixels.fill() lines will look more like typical usage.

For 2., here's maybe a way to change wheel:

def wheel(pos):
    # Input a value 0 to 255 to get a color value.
    # The colours are a transition r - g - b - back to r.
    if pos < 0 or pos > 255:
        r = g = b = 0
    elif pos < 85:
        r = int(pos * 3)
        g = int(255 - pos*3)
        b = 0
    elif pos < 170:
        pos -= 85
        r = int(255 - pos*3)
        g = 0
        b = int(pos*3)
    else:
        pos -= 170
        r = 0
        g = int(pos*3)
        b = int(255 - pos*3)
    return (r, g, b) if ORDER == neopixel.RGB or ORDER == neopixel.GRB else (r, g, b, 0)

[kattni]

That's the thing that caught my eye in the first place. I'll try to work in this suggestion.

[caternuson]

Yeah. Much better!