You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: