The expected result here (I argue) would be (48, False), but (probably because Shape is a named tuple under the hood) we get the not-very-useful result shown above.
Obviously in this case you can do (x+y).shape() but that's not always easy or possible (I hit a particular case involving an Enum)
The text was updated successfully, but these errors were encountered:
So there are two unrelated issues here. First, that currently you can do shape + shape and the result is never desirable. We should fix that by not using namedtuple while still allowing to destructure shapes using width, signed = shape. (Is that possible? I think we can override __iter__ to do it...)
Second, the idea of overloading the + operation on shapes to do something not really related to addition. It doesn't seem like a good idea to me, but we can discuss it in a different issue.
Oh sorry, you mean comparing for equality, not for ordering. Yeah let's preserve that, we can always deprecate it later if it turns out to cause issues.
Shape
s implement__add__
, but adding them is currently not useful:The expected result here (I argue) would be
(48, False)
, but (probably becauseShape
is a named tuple under the hood) we get the not-very-useful result shown above.Obviously in this case you can do
(x+y).shape()
but that's not always easy or possible (I hit a particular case involving anEnum
)The text was updated successfully, but these errors were encountered: