3 ms·

I remain unconvinced that the utility in the scenarios you describe outweighs the overhead in scenarios where it is irrelevant.

morelisp 6y ago
Please look at languages with good structural typing (e.g. Go - not so powerful but lots of syntactic convenience - and TypeScript - lots of power but you pay in compilation time, albeit not worse than mypy). If mypy is doomed to remain marginal it is because it picked a poor type system for the language it tries to support, not because stricter typing generally is the wrong choice for that language.
sseagull 6y ago
To each their own. I find almost all functions I write are really designed with one type in mind anyway. One difference may be if you primarily work in your own projects or work with other people’s projects. And how skilled the other developers are. In my own projects I instinctively know the types, but not in other projects, and having the types documented allows me to make changes much more quickly.
- musingsole 6y ago
  > One difference may be if you primarily work in your own projects or work with other people’s projects. Type-advocates throw this around all the time as if it's not the most patronizing thoughtpattern. Yes, I work on a good sized project with another 15 engineers using Python for the backend and angular for the frontend. If scale were going to reveal something dramatically different than whatever toy algorithms you might imagine I'm playing with...it would've happened by now.
  - sseagull 6y ago
    I think you took this differently than what I intended, although that is partly my fault. What I meant was more along the lines of “do you regularly jump into the deep end on new projects that were started/maintained by someone else?” Doing that is what made me a believer. Jumping into my current project, taking over from some else, was a nightmare without types. I had no idea if something was a string, a dict, a dataclass, a custom class, etc, with only vague hints based on how it was being used. These obviously had “types”, and the functions were designed for only one set of types. I just couldn’t remember what. “Your own” doesn’t necessarily mean small or toy. But more about consistently working in familiar code bases where you are already familiar with what types are flowing around. I think of these kinds of types as enforced documentation. It’s not for you (necessarily), it’s for other people.
6gvONxR4sf7o 6y ago
Even as nothing more than lightweight machine checked documentation, mypy is still a win. And just like you might write a few paragraphs of docs for one function and no docs at all for another, you can specify the hell out of one function's types and lean another completely unannotated. Mypy is an amazing middle ground because you don't need to move your whole codebase. The overhead is as much or as little as you like.

morelisp 6y ago

Please look at languages with good structural typing (e.g. Go - not so powerful but lots of syntactic convenience - and TypeScript - lots of power but you pay in compilation time, albeit not worse than mypy). If mypy is doomed to remain marginal it is because it picked a poor type system for the language it tries to support, not because stricter typing generally is the wrong choice for that language.

sseagull 6y ago

To each their own. I find almost all functions I write are really designed with one type in mind anyway. One difference may be if you primarily work in your own projects or work with other people’s projects. And how skilled the other developers are. In my own projects I instinctively know the types, but not in other projects, and having the types documented allows me to make changes much more quickly.

musingsole 6y ago
> One difference may be if you primarily work in your own projects or work with other people’s projects. Type-advocates throw this around all the time as if it's not the most patronizing thoughtpattern. Yes, I work on a good sized project with another 15 engineers using Python for the backend and angular for the frontend. If scale were going to reveal something dramatically different than whatever toy algorithms you might imagine I'm playing with...it would've happened by now.
- sseagull 6y ago
  I think you took this differently than what I intended, although that is partly my fault. What I meant was more along the lines of “do you regularly jump into the deep end on new projects that were started/maintained by someone else?” Doing that is what made me a believer. Jumping into my current project, taking over from some else, was a nightmare without types. I had no idea if something was a string, a dict, a dataclass, a custom class, etc, with only vague hints based on how it was being used. These obviously had “types”, and the functions were designed for only one set of types. I just couldn’t remember what. “Your own” doesn’t necessarily mean small or toy. But more about consistently working in familiar code bases where you are already familiar with what types are flowing around. I think of these kinds of types as enforced documentation. It’s not for you (necessarily), it’s for other people.

6gvONxR4sf7o 6y ago

Even as nothing more than lightweight machine checked documentation, mypy is still a win. And just like you might write a few paragraphs of docs for one function and no docs at all for another, you can specify the hell out of one function's types and lean another completely unannotated. Mypy is an amazing middle ground because you don't need to move your whole codebase. The overhead is as much or as little as you like.