Static types are great, but not exactly what would have helped here, any decent language or at least a linter should catch the use of a not declared identifier.
classMyClass:
def__init__(self, x: int):
self.whatever: int = x
deffoo(x: MyClass) -> int:
return x.whatevr
Any decent IDE would give you an error for unresolved attribute. Likewise it would warn you of type error if the type of x.whatever didn’t match the return type of foo()
Nope, don’t need to. WebStorm can even detect nonexistent attributes for objects whose format the back-end decides, and tbh I’m not sure what sort of sorcery it uses.
Yeah IntelliJ does amazingly without type annotations but even it can’t do everything. E.g. if you’re using libraries without type annotations, or if you don’t call functions with every possible type (is your testing that good? No.)
Static types have other benefits anyway so you should use them even if everyone in your team uses IntelliJ.
Yeah, our company has been meaning to transition to them for a while. I started saying Jsdoc comments but people complained about the pollution. Then I said fine, we’ll do TypeScript one day instead.
That one day has yet to come. I don’t actually get to decide much at this company, after all. Aah, technical debt.
I’ve never done it but apparently you can actually gradually transition to Typescript one file at a time by renaming them from .js to .ts. Might help a bit. Good luck anyway!
You’re both right. It’s possible to write code that gets linted well in Python, yes, but you’re often not working with just your code. If a library doesn’t use typing properly, not a lot to be done without a ton more effort.
Static types are great, but not exactly what would have helped here, any decent language or at least a linter should catch the use of a not declared identifier.
def foo(x): return x.whatevrNo linter is going to catch that.
class MyClass: def __init__(self, x: int): self.whatever: int = x def foo(x: MyClass) -> int: return x.whatevrAny decent IDE would give you an error for unresolved attribute. Likewise it would warn you of type error if the type of
x.whateverdidn’t match the return type offoo()Yes because you used static type annotations. This thread was about code that doesn’t use static types (or static type annotations/hints).
Nope, don’t need to. WebStorm can even detect nonexistent attributes for objects whose format the back-end decides, and tbh I’m not sure what sort of sorcery it uses.
Yeah IntelliJ does amazingly without type annotations but even it can’t do everything. E.g. if you’re using libraries without type annotations, or if you don’t call functions with every possible type (is your testing that good? No.)
Static types have other benefits anyway so you should use them even if everyone in your team uses IntelliJ.
Yeah, our company has been meaning to transition to them for a while. I started saying Jsdoc comments but people complained about the pollution. Then I said fine, we’ll do TypeScript one day instead.
That one day has yet to come. I don’t actually get to decide much at this company, after all. Aah, technical debt.
I’ve never done it but apparently you can actually gradually transition to Typescript one file at a time by renaming them from
.jsto.ts. Might help a bit. Good luck anyway!You’re both right. It’s possible to write code that gets linted well in Python, yes, but you’re often not working with just your code. If a library doesn’t use typing properly, not a lot to be done without a ton more effort.
It’s python, just use type hinting already and your linter will catch that.
Also some winters can look at the use of food and see the type being passed in.
Autocorrect got you pretty bad, there.
I was very confused, why we’re suddenly talking about rationing food during winter. 🙃
Holy crap that’s wild, new phones autocorrect is out to get me
Yes you can use static type hinting and the static type checker (Mypy or Pyright) will catch that. Linters (Pylint) won’t.