7 ms·

Mypy will only ever make it into a small fragment of Python code. Its existence is more likely an example of the those insistent on type checking crossing the p

Mypy will only ever make it into a small fragment of Python code. Its existence is more likely an example of the those insistent on type checking crossing the picket line and bringing their last holdout features to the language than it is an acceptance that duck typing is not the way. For the record, duck typing is the way. Mypy is a curiosity to me; I'm happy those who need it are getting that itch scratched; I'm happier it's boxed away from what I work with.

throwaway894345 6y ago
> Mypy will only ever make it into a small fragment of Python code. I don't think this has to be the case. If it got serious investment and the Python community was more open to making ergonomic syntax improvements so type annotations could be natural, we could see improvement. Similarly, I think it would need to figure out a saner solution to finding/loading type annotations, because the current set up and error messaging are immensely painful. I also don't know if Mypy will ever be sufficiently performant so long as it's written in Python (I think people really underestimate the difference between instant feedback and a delay of several seconds). Having good editor support would also drive adoption. If Mypy were able to improve on all of these distinct problem areas, I think more people would opt into type annotations naturally, but it certainly feels like Mypy is being treated as a thing to pacify the people who whine about static typing (of course I don't think that's the real intention, only how it comes across).
sseagull 6y ago
I thought like you at one point, but then jumped into a moderately-sized project that I was unfamiliar with. It took months to get an intuition for what the data was that was being passed around. Inside a function you need modify, you are passed a foo. What can you do with it? Take the length? Add a number to it? You don't know unless you know the type, and then the only place that info exists is in your head. Why not write it down in a way that can be checked and therefore never get out of date, like comments or some weird reincarnation of Hungarian notation? As a bonus: Editors will tell you when you are passing incorrect types to functions before you even run your tests. No more strings accidentally treated as lists! I am now absolutely convinced that types are important, even in python.
- musingsole 6y ago
  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.
bitwize 6y ago
No, no, no. Strong static typing is an unmitigated win. A stitch in time saves nine: with static typing you can check for type constraint violations at compile time that would otherwise throw runtime errors, eliminating a large class of bugs before your program even runs. What's more, with static typing your IDE can provide you with more helpful guidance by immediately showing you the valid method names associated with an object, type-checking their parameters as you use them, and suggesting possible parameters of the required types from the variables currently in scope. With dynamic/duck typing, you give all that up -- for no clear advantage. Use static typing in a project of significant size. Always.
- musingsole 6y ago
  > eliminating a large class of bugs before your program even runs And introducing complexity you have to resolve before your program even runs too! Complexity you have to solve. Static typing systems require you to do more design upfront. And more importantly, in your head! The most you can do is run your compiler and it'll tell you if you got it right. If not, just try again! Dynamic systems will encourage you to code flexibility from the beginning. You may have to run your system to expose a class bugs...but so? I was going to run it anyway. All these conversations are just about moving work around and when it gets done. Most problems are solved equally by a dynamic or static type system. However, static type systems inherently require more boilerplate. At the end of the day, you just rarely need it to do anything of importance.
  - phailhaus 6y ago
    Refactoring is basically impossible to do confidently in undisciplined dynamic codebases because you have not documented your types in the first place. Every codebase you have ever worked with is typed. You can either decide to ignore it and push the burden of memorizing what they are onto your developers, slowing your iteration rate, or you can spend the up front time to formalize it and let a program tell you what bugs you have. Those bugs already existed, it's not the type system's fault for pointing them out. The formalization step also allows you to encode business logic, where it would not otherwise exist. Suppose you have a system with documents. Every document has a length property...today. So in an untyped codebase, you've been doing just fine assuming it exists, and "just running the code" has found no issues. But technically, it doesn't always exist, and this fact isn't encoded anywhere. It breaks. If you had just defined a document type, then you could simply update the length type and let mypy tell you literally all the places where the bug would arise. Or, it would have allowed you to avoid making that assumption in the first place, rather than trying to make sure every developer memorizes this useless fact and writing tests every time the length property is touched.
glyph 6y ago
This made me curious, so I’m taking a poll. https://twitter.com/glyph/status/1372640855807250432?s=21 https://twitter.com/glyph/status/1372640855807250432?s=21
- glyph 6y ago
  The results of the poll are in, and 59.6% of the 699 respondents said that they're either using it already or will be using it within the year. This isn't necessarily a representative sample, my followers are probably on the more advanced end of the Python spectrum, but 700 people (including myself) isn't nothing, either. I think it's likely that type annotations will be available for the majority of Python libraries.

throwaway894345 6y ago

> Mypy will only ever make it into a small fragment of Python code. I don't think this has to be the case. If it got serious investment and the Python community was more open to making ergonomic syntax improvements so type annotations could be natural, we could see improvement. Similarly, I think it would need to figure out a saner solution to finding/loading type annotations, because the current set up and error messaging are immensely painful. I also don't know if Mypy will ever be sufficiently performant so long as it's written in Python (I think people really underestimate the difference between instant feedback and a delay of several seconds). Having good editor support would also drive adoption. If Mypy were able to improve on all of these distinct problem areas, I think more people would opt into type annotations naturally, but it certainly feels like Mypy is being treated as a thing to pacify the people who whine about static typing (of course I don't think that's the real intention, only how it comes across).

sseagull 6y ago

I thought like you at one point, but then jumped into a moderately-sized project that I was unfamiliar with. It took months to get an intuition for what the data was that was being passed around. Inside a function you need modify, you are passed a foo. What can you do with it? Take the length? Add a number to it? You don't know unless you know the type, and then the only place that info exists is in your head. Why not write it down in a way that can be checked and therefore never get out of date, like comments or some weird reincarnation of Hungarian notation? As a bonus: Editors will tell you when you are passing incorrect types to functions before you even run your tests. No more strings accidentally treated as lists! I am now absolutely convinced that types are important, even in python.

musingsole 6y ago
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.

bitwize 6y ago

No, no, no. Strong static typing is an unmitigated win. A stitch in time saves nine: with static typing you can check for type constraint violations at compile time that would otherwise throw runtime errors, eliminating a large class of bugs before your program even runs. What's more, with static typing your IDE can provide you with more helpful guidance by immediately showing you the valid method names associated with an object, type-checking their parameters as you use them, and suggesting possible parameters of the required types from the variables currently in scope. With dynamic/duck typing, you give all that up -- for no clear advantage. Use static typing in a project of significant size. Always.

musingsole 6y ago
> eliminating a large class of bugs before your program even runs And introducing complexity you have to resolve before your program even runs too! Complexity you have to solve. Static typing systems require you to do more design upfront. And more importantly, in your head! The most you can do is run your compiler and it'll tell you if you got it right. If not, just try again! Dynamic systems will encourage you to code flexibility from the beginning. You may have to run your system to expose a class bugs...but so? I was going to run it anyway. All these conversations are just about moving work around and when it gets done. Most problems are solved equally by a dynamic or static type system. However, static type systems inherently require more boilerplate. At the end of the day, you just rarely need it to do anything of importance.
- phailhaus 6y ago
  Refactoring is basically impossible to do confidently in undisciplined dynamic codebases because you have not documented your types in the first place. Every codebase you have ever worked with is typed. You can either decide to ignore it and push the burden of memorizing what they are onto your developers, slowing your iteration rate, or you can spend the up front time to formalize it and let a program tell you what bugs you have. Those bugs already existed, it's not the type system's fault for pointing them out. The formalization step also allows you to encode business logic, where it would not otherwise exist. Suppose you have a system with documents. Every document has a length property...today. So in an untyped codebase, you've been doing just fine assuming it exists, and "just running the code" has found no issues. But technically, it doesn't always exist, and this fact isn't encoded anywhere. It breaks. If you had just defined a document type, then you could simply update the length type and let mypy tell you literally all the places where the bug would arise. Or, it would have allowed you to avoid making that assumption in the first place, rather than trying to make sure every developer memorizes this useless fact and writing tests every time the length property is touched.

glyph 6y ago

This made me curious, so I’m taking a poll. https://twitter.com/glyph/status/1372640855807250432?s=21 https://twitter.com/glyph/status/1372640855807250432?s=21

glyph 6y ago
The results of the poll are in, and 59.6% of the 699 respondents said that they're either using it already or will be using it within the year. This isn't necessarily a representative sample, my followers are probably on the more advanced end of the Python spectrum, but 700 people (including myself) isn't nothing, either. I think it's likely that type annotations will be available for the majority of Python libraries.