Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with the gist of your comment.

I will add that, in my experience, having type annotations that are unreliable, cumbersome, with so many edge cases and requiring this kind of magic (e.g. "if TYPE_CHECKING", etc) which is beyond most "casual" Python users effectively means type annotations are a very hard sell for most non-hardcore team mates.

I've been in a position to try improving processes and code quality of the Python codebase, and introducing mypy and type annotations has always been a very hard sell. The team just won't accept the benefits, given the difficulties in using it. If only Python made it easier and more reliable, but the current state is a mess.

I come from the static typing world, so of course I see the benefits. But most/all of my team mates don't, and so they see this as some really odd hoops I want them to jump through, for minimal benefit (in their eyes).



I think type annotations are extremely valuable even if you don't use mypy. On my team we basically use them as comments that are understood by the IDE, but aren't enforced. Of course comments can lie, but appeasing mypy really is a lot of work, and I would generally rather have a slightly dishonest but mostly correct type hint than some TypeVar monstrosity or, worse, Any.


Hm. Type annotations as comments is the ultimate annoyance to my coworkers. They really do see them as "what's the point" in that case. Plus, like you say, they are misleading. The look like code, but they don't do anything.


I think if you're already documenting function argument types, there is no point. But in my experience it's unworkable to ask people to write full documentation for every function, but requiring type hints is not as hard and is nearly as useful. It is a little weird that they look like code, but I think you get used to it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: