Type annotations that have no compile-time or runtime effect are worse than not having annotations at all. They will mislead readers of the code, giving them a false sense of security. Debugging will be made harder since we'll start relying on these annotations being true, even if they are not.
Sorry, it's a bad language that allows:
number : int = "Hello"
This doesn't help anything at all.
It would have been better off to just allow inline comments and you'd get the desired effect without the artificial "safety"
By the same thinking, why do we name variables meaningful names? If a compiler lets me write num_tries = 'five', does it follow that we should only name our variables generic names like x and y? After all, num_tries might give readers of the code false sense of security. :-P
Ofc it's always easyer to tell why something is bad, than trying to see how it could add improvement. Just use MyPy as part of your Unit test suite and you get immediate value for your CI pipeline. See it like adding some "intentions" (that also your IDE understands #refactorings) to your code and let them be checked for consistency. From a small project point of view that may not seem like a big plus, especially compared to the additional work. But from a more professional point of view this was missing for way to long.
I'm not saying it doesn't have uses, I'm saying that the basic syntax makes the code worse than it was before. The lying about the types will create more bugs.
This type of behaviour is very unusual for a language feature. Most features add value of some kind, or at least sit at zero value. This one actively reduces the ability of somebody to write proper code by misleading them about what is happening.
The fact it has some benefits does not outweigh these guaranteed negatives.
After several months your comment seems wrong. Large number of questions on /r/learnpython wouldn't have been even asked if using type annotations + mypy.
Typical mistake: missing int() when using input() to read int values.
Wait, it's just to turn the code more clear and avoid have to guess types to deal with function/methods parameters. Python is not a compiled language, all python programmers know that and won't use this feature like compile time checking for type security.
Actually it's much cleverer than having a comment:
Your IDE can pick up the difference much more easily and warn you, plus the typing information itself is syntax-checked.
Tools (like MyPy) can enforce it.
Yes, it can be ignored or overridden by a developer - that could be useful inside library internals.
User-defined metatypes, like the UserId example given in the docs, aren't possible with your comments.
For an example of the latter point:
fromtypingimportNewTypeUserId=NewType('UserId',int)user1=UserId(1)user2=UserId(2)# user1 and user2 are simply integer values, but with typing info.
user=get_user(user1)# OK
user=get_user(user2)# OK
user3=user1+user2# OK, these are ints!
user=get_user(user3)# Not OK! That's not a UserId
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Type annotations that have no compile-time or runtime effect are worse than not having annotations at all. They will mislead readers of the code, giving them a false sense of security. Debugging will be made harder since we'll start relying on these annotations being true, even if they are not.
Sorry, it's a bad language that allows:
This doesn't help anything at all.
It would have been better off to just allow inline comments and you'd get the desired effect without the artificial "safety"
By the same thinking, why do we name variables meaningful names? If a compiler lets me write num_tries = 'five', does it follow that we should only name our variables generic names like x and y? After all, num_tries might give readers of the code false sense of security. :-P
Ofc it's always easyer to tell why something is bad, than trying to see how it could add improvement. Just use MyPy as part of your Unit test suite and you get immediate value for your CI pipeline. See it like adding some "intentions" (that also your IDE understands #refactorings) to your code and let them be checked for consistency. From a small project point of view that may not seem like a big plus, especially compared to the additional work. But from a more professional point of view this was missing for way to long.
plus: what Dave Cridland said.
I'm not saying it doesn't have uses, I'm saying that the basic syntax makes the code worse than it was before. The lying about the types will create more bugs.
This type of behaviour is very unusual for a language feature. Most features add value of some kind, or at least sit at zero value. This one actively reduces the ability of somebody to write proper code by misleading them about what is happening.
The fact it has some benefits does not outweigh these guaranteed negatives.
After several months your comment seems wrong. Large number of questions on /r/learnpython wouldn't have been even asked if using type annotations + mypy.
Typical mistake: missing int() when using input() to read int values.
I agree, that's why I don't use them yet. I might start looking into them if I were to adopt mypy which is a compile time static type checker...
Wait, it's just to turn the code more clear and avoid have to guess types to deal with function/methods parameters. Python is not a compiled language, all python programmers know that and won't use this feature like compile time checking for type security.
Actually it's much cleverer than having a comment:
For an example of the latter point: