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()
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.
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!
I don’t want to get into an Internet argument over pedantry. Linter is often used as a catch-all term for static analysis tools.
Wikipedia defines it as
Lint is the computer science term for a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs.
Catching type errors and attribute errors would fit under this description, if you use a different, more precise definition at your workplace, cool, then we just have different definitions for it. The point is that your IDE should automatically detect the errors regardless of what you call it.
In common usage a linter detects code that is legal but likely a mistake, or code that doesn’t follow best practice.
Although static type checkers do fit in that definition, that definition is overly broad and they would not be called a “linter”.
Here is how static type checkers describe themselves:
Pyright is a full-featured, standards-based static type checker for Python.
Mypy is a static type checker for Python.
TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.
Sorbet is a fast, powerful type checker designed for Ruby.
Here is how linters describe themselves:
Pylint is a static code analyser for Python 2 or 3. … Pylint analyses your code without actually running it. It checks for errors, enforces a coding standard, looks for code smells, and can make suggestions about how the code could be refactored.
(Ok I guess it’s a bit redundant for Pylint to say it is a linter.)
Eslint: The pluggable linting utility for JavaScript and JSX
Clippy: A collection of lints to catch common mistakes and improve your Rust code.
Ruff: An extremely fast Python linter and code formatter, written in Rust.
You get the idea… Linters are heuristic and advisory. Quite different to static type checking.
If you have done the minimum and at least set a type hint, or if your ide is smart enough to check what calls the function and what it passes, then it’ll be flagged.
classMyClass:
def__init__(self, value):
self._whatever = value
@propertydefwhatever(self):
returnself._whatever
Personally, I would type hint all of that but I’m just showing how you can do it without types. Your linter should be smart enough to say “hey dumbass did you mean this other thing”? Also since we didn’t create a setter you can’t arbitrarily overwrite the value of whatever so thats neat.
And I’ll just say before I post that I’m on mobile and I’m sorry if the formatting is fucked. I’m not going to fix it.
What’s the purpose of foo? Why an ambiguous single character variable? What if the property was there but the value was null? Why not use (assuming JS) optional chaining?
It’s an example to demonstrate that linters cannot reliably detect variable name typos - you need static types. None of the stuff you mentioned is relevant.
The typo in your example is also undetectable by linters. I think you’re missing the point.
This is literally a getter function. How is a getter awful code? It’s the simplest function there is. The only function simpler than that is returning the input itself.
How does “foo” mean “get”? Half the battle of writing correct code is writing code that’s easy to interpret. Do you always look at the guts of every function you’re about to use?
…for people who refuse to use static types.
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()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.
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!Python doesn’t check the types of function headers though. They’re only hints for the programmer.
OP suggested that linters for python won’t catch attribute errors, which they 100% will if you use type hints, as you should.
What happens at runtime is really relevant in this case.
Linters 100% won’t. A static type checker is not a linter.
I don’t want to get into an Internet argument over pedantry. Linter is often used as a catch-all term for static analysis tools.
Wikipedia defines it as
Catching type errors and attribute errors would fit under this description, if you use a different, more precise definition at your workplace, cool, then we just have different definitions for it. The point is that your IDE should automatically detect the errors regardless of what you call it.
In common usage a linter detects code that is legal but likely a mistake, or code that doesn’t follow best practice.
Although static type checkers do fit in that definition, that definition is overly broad and they would not be called a “linter”.
Here is how static type checkers describe themselves:
Here is how linters describe themselves:
(Ok I guess it’s a bit redundant for Pylint to say it is a linter.)
You get the idea… Linters are heuristic and advisory. Quite different to static type checking.
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.
Not with an example that simple and poor, no.
If you have done the minimum and at least set a type hint, or if your ide is smart enough to check what calls the function and what it passes, then it’ll be flagged.
Always love seeing the trope:
How would you make it non-awful, without specifying static types?
I guess, a unit test would catch it, but needing 100% test coverage to catch typos isn’t exactly great…
I would do
class MyClass: def __init__(self, value): self._whatever = value @property def whatever(self): return self._whateverPersonally, I would type hint all of that but I’m just showing how you can do it without types. Your linter should be smart enough to say “hey dumbass did you mean this other thing”? Also since we didn’t create a setter you can’t arbitrarily overwrite the value of whatever so thats neat.
And I’ll just say before I post that I’m on mobile and I’m sorry if the formatting is fucked. I’m not going to fix it.
I use a spell checker in my IDE. It would catch this.
What’s awful about this example? The only thing I do is access an object member. Does your code not do that??
What’s the purpose of foo? Why an ambiguous single character variable? What if the property was there but the value was null? Why not use (assuming JS) optional chaining?
I’d approach it more like this:
function getWhatevrProp(userData) ( const default = { whatevr: "n/a" }; return { ...default, ...userData }.whatevr; }Sorry, read too fast the first time. It’s more likely Python. I also don’t know Python well enough to give recommendations on that.
Lmao, and they say dynamic typing is supposed to speed up the developer.
It’s an example to demonstrate that linters cannot reliably detect variable name typos - you need static types. None of the stuff you mentioned is relevant.
The typo in your example is also undetectable by linters. I think you’re missing the point.
This is literally a getter function. How is a getter awful code? It’s the simplest function there is. The only function simpler than that is returning the input itself.
How does “foo” mean “get”? Half the battle of writing correct code is writing code that’s easy to interpret. Do you always look at the guts of every function you’re about to use?
It’s a one line function in an example. It’s a getter.