31–40 of 48 posts
non-clickbait title: Python: Mistyping a character in your code can bite you. Any IDE or linter worth its salt would catch this for you.
Once a coworker came to me with a program that was unexpectedly failing, and it turned out that somewhere in the code there was a function that takes a callable, but instead of
something(iterable, func)
something(iterable, func())
Nonetheless, personally I’d take that over most other options for run of the mill progamming tasks.
This is a weird article to me. There seems to be an implicit condemnation of Python for this new feature resulting in non-error, unexpected behavior under certain typoes, despite the fact that that is true for literally any typo that results in valid code in any language (such as, e.g., = instead of ==). I don't understand how it would be possible to add a new syntactic option without being "bit". Regarding type hint…
There were some people who thought that trying to bolt a type system on to Python was a bad idea. A common response to them was "you don't have to use it; you can ignore it and you're no worse off than you were before". I think it's reasonable for him to point out that this isn't quite true.
Understanding the basic syntax for assignment isn’t a high bar to clear. While it’s maybe not ideal to use colons for both the “assignment-like” separator between keys and values inside dictionaries and the annotation of types, introducing any new syntax features into a language that’s been around for decades is never without compromise. Colons are also used at the end of block statements and in index ranges and nobo…
The problem is not understanding, it's fat-fingering (especially when dict literals and dict comps use `:`). > type annotations just delayed your runtime error by one line. Or it introduces a subtle bug because this was intended as a reassignment or somesuch.
You’re right I’m being uncharitable by saying “understanding”. I’m annoyed he bothered writing an accusatory blog post about this aspect of the language without mentioning any of the alternative syntax proposals helpfully discussed in the PEP, or exploring why annotations work this way. The designers have been very transparent and conservative in considering different ways of doing it, and the OP doesn’t offer any ideas for improving the interpreter, or note that the behavior he’s complaining about will be fixed in 3.8.
It seems odder to me that 42 is a valid type hint than that the LHS can be an expression. But I share with most of the others here the opinion that this really isn’t a problem with Python. Every language makes trade offs, and python gives you incredible flexibility and expressiveness in exchange for a lack of certain guardrails. Once a coworker came to me with a program that was unexpectedly failing, and it turned ou…
This would also not be accepted by mypy.
This is a weird article to me. There seems to be an implicit condemnation of Python for this new feature resulting in non-error, unexpected behavior under certain typoes, despite the fact that that is true for literally any typo that results in valid code in any language (such as, e.g., = instead of ==). I don't understand how it would be possible to add a new syntactic option without being "bit". Regarding type hint…
There were some people who thought that trying to bolt a type system on to Python was a bad idea. A common response to them was "you don't have to use it; you can ignore it and you're no worse off than you were before". I think it's reasonable for him to point out that this isn't quite true.
non-clickbait title: Python: Mistyping a character in your code can bite you. Any IDE or linter worth its salt would catch this for you.
Can you recommend a particular linter? I use flake8, which does not warn for this. I just tested pylint which also does not appear to warn for this.
I would assume mypy would cause an error.
Earlier quoted context omitted.
Can you recommend a particular linter? I use flake8, which does not warn for this. I just tested pylint which also does not appear to warn for this.
PyCharm would highlight the expression after : as a type that was not imported correctly (or an expression that is not a type). I would assume mypy would cause an error.
>>> [][0]
Traceback (most recent call last):
File "", line 1, in
IndexError: list index out of range
>>>
>>> [][0] : "bug"
>>>This is an idiotic article because a static analyzer like mypy will find this in a hurry: > error: Invalid type: try using Literal[42] instead? If you don't use the analyzer, the problem is you.
mypy is a very cool experimental project (as their own webpage calls it), but I wouldn't fault anyone for not running it on their program.