x = None # type: int)
__init__and other methods. I also think that with PEP 526 this will be the future (also with things like class-based NamedTuple declarations and possibly https://github.com/ericvsmith/dataclasses).
class Point(NamedTuple('Point', [('x', float), ('y', float)])): def __add__(self, other: Point) -> Point: # E: error: Argument 1 of "__add__" incompatible with supertype "tuple" return Point(self.x + other.x, self.y + other.y)
NamedTupleis a subclass of
(1, 2) + (3, 4)is a pre-defined operation in python. I think it's unfortunate because deriving things like
namedtupleis a perfect idiom in non-typed python code; so it's sad to lose that idiom in typed python.
NamedTupleright? Maybe it's worth including in the tutorial at some point? It's kinda a nice pattern.
Point(1, 1) + SomethingElseInheritedFromTuple(1, 2), not caught at compile time. Now that it actually happened, I strengthened my opinion on that, and I no longer think using
def __add__(self, other: object)is an acceptable solution. The only solution I personally find acceptable is to not derive from
tuple, and just manually implement
__repr__, etc in my own generic class
MyTuplethat does not define
+and derive my
Point/etc. from that class. (Well, I could wrap a
MyTupleand forward the useful methods but not the ones I don't want. So I do get some code reuse.)
+meaning concatenation is reasonable. It's just an unfortunate reality for cases where
+needs to be pointwise.