3 ms·

I can only speak about my own experience: Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff.

by the_af 5y ago

I can only speak about my own experience: Most people I know writing Python don't use type hints because they are too much of a hurdle for very little payoff. The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. The type hints themselves are of dubious use. As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful.

wronglyprepaid 5y ago
> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. I use mypy daily on big codebases, it is fine, not fast, but fine. > The type hints themselves are of dubious use. They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing different. python with a static type checker running in strict mode is not fundementally different from Java's static type checking. > As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful. What do they lack that would make them useful?
- the_af 5y ago
  > The same as in literally every other language with static typing No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either. > [type hints] tell you when you make type errors Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking, but a form of notation for documentation. Seems wasteful, and I wish the Python community and tooling decided instead that they are for actually checking them. > What do they lack that would make them useful? Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so. I haven't found mypy to fill these requirements. It's so bad I cannot convince my coworkers to make the effort to write more type hints.
  - wronglyprepaid 5y ago
    > No, obviously not the same, otherwise I wouldn't be complaining. What is the difference? > They are not even on par with Typescript, which I'm not a fan of either. Go is not on par with Typescript or Python, I still don't think it is okay for people to just say fuckit and `interface{}` it all and it is still shit to work with code that does use `interface{}`. At least Python with mypy has null safety, something that Java and Go does not have. There are some places it is worse than other statically typed languages, others where it is better. > Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so. It is mypy. What actual type errors does mypy not catch that you want it to catch? Why can't you use it in the build pipeline? I do it every day, it catches all the errors it should. The one complaint I can maybe see is the duct type compatibility complaint, and it is not really something that comes up that often for me, and definitely not something I would say invalidates the whole concept.
    - the_af 5y ago
      > What is the difference? I'm not going to repeat myself, I already told you. I find mypy slow, unsatisfying, inconsistent, and it fails to catch many type errors. No, I'm not going to go look in my work laptop to give you an example. > There are some places it is worse than other statically typed languages, others where it is better. In most places it is way worse, and I'll find it very hard to find common ground with anyone who disagrees on this. Feel free to disagree, but I don't find this conversation useful.
  - Too 5y ago
    How big is your code base? I’ve worked with really large auto generated codes and mypy never took more than a minute or two to run. On more normal sized code bases it’s just a few seconds. It’s also incremental so subsequent runs are faster. Compare that to a c++ project where it’s not unusual to have 10, 15, 30 min build times. Or even worse, the time to wait for discovering the problem runtime in prod. The type hints also help in IDE navigation, where there is zero time to wait, pycharm can go to definition or find references in under a second.
  - 5y ago
seti0Cha 5y ago
Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.
- the_af 5y ago
  Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.
  - ledauphin 5y ago
    mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.
    - the_af 5y ago
      Not my experience!
      - Bedon292 5y ago
        What speed are you looking for in your CI pipline that you are not getting from mypy? Perhaps you are working on a much larger codebase than I am but the app I use it in takes under a minute. And all the unit tests take longer to run.
        deckiedan 5y ago
        A 25k LOC Django project - takes 15-20 minutes to run mypy... Unit tests take about 3 minutes. That's locally on a fast (ish) laptop. GH CI takes 10 minutes to run tests, so I'm a little hesitant to see how long mypy takes to run.
    - nas 5y ago
      Use "dmypy", it is fast.

by the_af 5y ago

wronglyprepaid 5y ago

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. I use mypy daily on big codebases, it is fine, not fast, but fine. > The type hints themselves are of dubious use. They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing different. python with a static type checker running in strict mode is not fundementally different from Java's static type checking. > As a fan and advocate of static typing, I find myself advocating for type hints anyway, but I must agree I often can't reply anything to my coworkers' objections, because Python type hints are truly not that useful. What do they lack that would make them useful?

the_af 5y ago
> The same as in literally every other language with static typing No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either. > [type hints] tell you when you make type errors Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking, but a form of notation for documentation. Seems wasteful, and I wish the Python community and tooling decided instead that they are for actually checking them. > What do they lack that would make them useful? Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so. I haven't found mypy to fill these requirements. It's so bad I cannot convince my coworkers to make the effort to write more type hints.
- wronglyprepaid 5y ago
  > No, obviously not the same, otherwise I wouldn't be complaining. What is the difference? > They are not even on par with Typescript, which I'm not a fan of either. Go is not on par with Typescript or Python, I still don't think it is okay for people to just say fuckit and `interface{}` it all and it is still shit to work with code that does use `interface{}`. At least Python with mypy has null safety, something that Java and Go does not have. There are some places it is worse than other statically typed languages, others where it is better. > Standardized, go-to tools that work in the build pipeline and that catch most errors without taking a long time to do so. It is mypy. What actual type errors does mypy not catch that you want it to catch? Why can't you use it in the build pipeline? I do it every day, it catches all the errors it should. The one complaint I can maybe see is the duct type compatibility complaint, and it is not really something that comes up that often for me, and definitely not something I would say invalidates the whole concept.
  - the_af 5y ago
    > What is the difference? I'm not going to repeat myself, I already told you. I find mypy slow, unsatisfying, inconsistent, and it fails to catch many type errors. No, I'm not going to go look in my work laptop to give you an example. > There are some places it is worse than other statically typed languages, others where it is better. In most places it is way worse, and I'll find it very hard to find common ground with anyone who disagrees on this. Feel free to disagree, but I don't find this conversation useful.
- Too 5y ago
  How big is your code base? I’ve worked with really large auto generated codes and mypy never took more than a minute or two to run. On more normal sized code bases it’s just a few seconds. It’s also incremental so subsequent runs are faster. Compare that to a c++ project where it’s not unusual to have 10, 15, 30 min build times. Or even worse, the time to wait for discovering the problem runtime in prod. The type hints also help in IDE navigation, where there is zero time to wait, pycharm can go to definition or find references in under a second.
- 5y ago

seti0Cha 5y ago

Have you looked at the tools recently? LSP + Pyright is very fast and plugins exist for many editors. Or maybe it's slow on larger codebases or very large files? I don't have that broad an experience yet, but so far it's been very good.

the_af 5y ago
Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.
- ledauphin 5y ago
  mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.
  - the_af 5y ago
    Not my experience!
    - Bedon292 5y ago
      What speed are you looking for in your CI pipline that you are not getting from mypy? Perhaps you are working on a much larger codebase than I am but the app I use it in takes under a minute. And all the unit tests take longer to run.
      - deckiedan 5y ago
        A 25k LOC Django project - takes 15-20 minutes to run mypy... Unit tests take about 3 minutes. That's locally on a fast (ish) laptop. GH CI takes 10 minutes to run tests, so I'm a little hesitant to see how long mypy takes to run.
  - nas 5y ago
    Use "dmypy", it is fast.