Closed rec closed 8 years ago
list
has exactly these methods to do list operations.
__add__
__iadd__
__mul__
__iadd__
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.
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
.
OOOPS, I forgot to put in __add__
and friends!
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.