4 ms·
I would like to note in this code example: class C(int): def __add__(self, other): return "no" # sigh -> class C(int): d
by jmholla 3y ago
I would like to note in this code example:
class C(int):
def __add__(self, other):
return "no" # sigh
->
class C(int):
def __add__(self, other: int) -> str:
return "no" # sigh
Proper type annotations and using strict mypy type checking will throw an error.
test.py:2: error: Return type "str" of "__add__" incompatible with return type "int" in supertype "int" [override]
This is again brought up later in the article.
I also thought it was odd to diverge into attempts to compile (against?) non-typed code. That seems at odds with the premise of the article.
This is still a really good article. Just a little meandering.
- tekknolagi 3y agoThe idea is that not all code in your code will be typed. So while at the typed callee everything is all hunky-dory, any random subclass might not be typed. The subclass could even be a C extension. EDIT: Also, the point is that even if it's well-typed, it can still go and execute arbitrary code. So you can't just specialize the callee. EDIT: Pushed and thanked you in the commit.
- BerislavLopac 3y ago> The idea is that not all code in your code will be typed. All Python code is always typed; it just might not be annotated. Even then, static analysis tools like mypy are pretty good at inferring types based on the code.