I'm going to write my honest opinion about this. I got to learn about type hinting in python a couple months ago(; I knew it existed long before that but didn't bother to learn about it until recently). While the idea seems promising at the first glance, I think the implementation could be much better, to say the least.
Adding type hints to python was performed in a way that got in the way of developers writing code instead of helping them to do so. It looks like a completely new language was suddenly embedded inside your python code, and makes the developer to write what seems like two languages interspersed on the same line.
First it has a steep learning curve(, and yes I mean the learning curve not the effort to apply the rules to an existing codebase, which is another story). Just consider the different types in the typing module the developer has to learn about to annotate variables instantiated from other popular types(built-in ones or otherwise) like list, tuple, re.Match, ...etc. You can't use the original types because they don't support the generic class syntax like list[int]; you have to instead rely on the equivalent ones from the typing module like List[int]. Even the syntax for specifying a generic class with a type parameter is inconvenient, relying on the indexing operator instead of some other clearer one. So you end up using two families of type names, one for constructing objects and another for annotating. Luckily this doesn't happen with user-defined types as they're supported to be used for both purposes.
And then consider the code changes. I should be honest to say that these changes are needed if you want a static type checker like mypy(which is the only one I've used so far) against your code, which seems the rational and right thing to do after you decide to add type hints(otherwise they'll turn out over time to be just another type of comments). Once you decide to use something like mypy, all hell gates are open. Suddenly some expressions that looked just fine and logical need restructuring and changes. Take for example containers or strings that we can use as boolean expressions; this no longer works because the type checker needs to see that you really mean to test their truth value(especially evident in return statements with functions returning bool). Another example is the need to convert many lambdas passed as parameters to functions to explicit standalone functions, just because the type checker can't sanitize the lambda syntax sufficiently(especially evident with third-party libraries, which I discuss later).
Sometimes the type checker is completely unable to understand what's written and seems like a very clear code snippet, like this question stackoverflow.com/questions/600296... I asked on stackoverflow about how to satisfy mypy without writing a lot of boilerplate code. Please don't get me wrong: I do appreciate the effort that has gone over the years to bring mypy and other type checkers to how they look now, but the deficiencies and shortcomings of these tools adversely affects the full picture of type hinting.
Now consider the conformance and adoption of third-party libraries and packages for type hinting. Very few libraries have done so, and even some very popular ones haven't put the effort to do(like the attrs library for example). This imposes that you must instruct your type checker to ignore uses and references to utilities from these third-party libraries which scanning your code, which still introduces many weaknesses contrary to what type hinting claimed and was intended for in the first place.
I'm still keen and intending to use type hints with my projects, but honestly the status quo of type hinting in python discourages developers from adopting and applying it as a mainstream practice while coding.
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.
I'm going to write my honest opinion about this. I got to learn about type hinting in python a couple months ago(; I knew it existed long before that but didn't bother to learn about it until recently). While the idea seems promising at the first glance, I think the implementation could be much better, to say the least.
Adding type hints to python was performed in a way that got in the way of developers writing code instead of helping them to do so. It looks like a completely new language was suddenly embedded inside your python code, and makes the developer to write what seems like two languages interspersed on the same line.
First it has a steep learning curve(, and yes I mean the learning curve not the effort to apply the rules to an existing codebase, which is another story). Just consider the different types in the
typingmodule the developer has to learn about to annotate variables instantiated from other popular types(built-in ones or otherwise) likelist,tuple,re.Match, ...etc. You can't use the original types because they don't support the generic class syntax likelist[int]; you have to instead rely on the equivalent ones from the typing module likeList[int]. Even the syntax for specifying a generic class with a type parameter is inconvenient, relying on the indexing operator instead of some other clearer one. So you end up using two families of type names, one for constructing objects and another for annotating. Luckily this doesn't happen with user-defined types as they're supported to be used for both purposes.And then consider the code changes. I should be honest to say that these changes are needed if you want a static type checker like mypy(which is the only one I've used so far) against your code, which seems the rational and right thing to do after you decide to add type hints(otherwise they'll turn out over time to be just another type of comments). Once you decide to use something like mypy, all hell gates are open. Suddenly some expressions that looked just fine and logical need restructuring and changes. Take for example containers or strings that we can use as boolean expressions; this no longer works because the type checker needs to see that you really mean to test their truth value(especially evident in return statements with functions returning bool). Another example is the need to convert many lambdas passed as parameters to functions to explicit standalone functions, just because the type checker can't sanitize the lambda syntax sufficiently(especially evident with third-party libraries, which I discuss later).
Sometimes the type checker is completely unable to understand what's written and seems like a very clear code snippet, like this question stackoverflow.com/questions/600296... I asked on stackoverflow about how to satisfy mypy without writing a lot of boilerplate code. Please don't get me wrong: I do appreciate the effort that has gone over the years to bring mypy and other type checkers to how they look now, but the deficiencies and shortcomings of these tools adversely affects the full picture of type hinting.
Now consider the conformance and adoption of third-party libraries and packages for type hinting. Very few libraries have done so, and even some very popular ones haven't put the effort to do(like the attrs library for example). This imposes that you must instruct your type checker to ignore uses and references to utilities from these third-party libraries which scanning your code, which still introduces many weaknesses contrary to what type hinting claimed and was intended for in the first place.
I'm still keen and intending to use type hints with my projects, but honestly the status quo of type hinting in python discourages developers from adopting and applying it as a mainstream practice while coding.