timedata-org / old-timedata

Time arts data - high-performance color processing in C++ and Python.
7 stars 3 forks source link

Make `ColorList` look "exactly" like `list`. #57

Closed rec closed 8 years ago

rec commented 8 years ago

Right now we look more like numpy lists - +, *, - etc do arithmetic operations.

I think this is a bad idea. We look an awful lot like the classic Python list - let's go all the way.

rec commented 8 years ago

list has exactly these methods to do list operations.

I'm going to get rid of most arithmetic operations - like e.g __floor__ - because we already have methods on ColorList that do the mutation.

I'm going to have only mutators for the arithmetic operations - i.e. mul, sub, rsub. If you want a copy, you can do e.g. my_list.copy().add(3).

And... I think that covers it.

rec commented 8 years ago

Should I do the same thing to Color?

Right now, it's really convenient - well, here are the two choices

Colors.red + Colors.green / 2
Colors.red.add(Colors.green.div(2))

The first case is clearly "more fun" but now Color isn't behaving like a tuple any more.

Tuples would work like this:

Colors.red + Colors.green
>>> (1, 0, 0, 0, 1, 0)

which is not really very useful. ....

I can make arguments both ways tbh.

But I'm sort of tempted to leave it like it is, and here's why.

The "list-ness" of ColorList is its predominant feature. But the "tupleness" of Color is not nearly as important - indeed, the order rgb is arbitrary.

So ColorList is "a list" and should look just like a list.

But Color is "a color" which happens to have some convenience functions similar to tuple or list to help you unpack. So for example you wouldn't normally say color[1] but color.green.

rec commented 8 years ago

OOOPS, I forgot to put in __add__ and friends!