4 ms·

I guess someone posted this in response to this HN post: https://news.ycombinator.com/item?id=19473631 https://news.ycombinator.com/item?id=19473631 People te

I guess someone posted this in response to this HN post: https://news.ycombinator.com/item?id=19473631 https://news.ycombinator.com/item?id=19473631 People tend to do that on HN. So, for those of us who don’t use Python type checking, which of the 4 checkers do we choose? Google, Facebook, Dropbox, or the new one: Pyright?

CloudYeller 8y ago
Not to be a total smartass, but if your Python codebase is not that big yet, then the correct answer is none of the above- rewrite in a compiled language if you find the lack of static checks disturbing. I have been using "type checked" python for a year and let me tell you, it is not even 10% as good as having a real compiler. Python type checkers are not even close to 100% accuracy. If you're going to use a python type checker, use the one that has the most dev resources behind it. Which probably means, whichever company has the most internal python code, which is probably Google. So pytype. But bear in mind, these things are only sensible when you've written so much python code that it's too late to rewrite in a better language. If you're in that situation, even though these checkers are far from perfect, they are a massive improvement over plain python.
- melling 8y ago
  I only asked for an evaluation of the current Python checkers, not a philosophy lesson. In theory there's no difference between theory and practice, but in practice there is. So, in practice which is the best current Python type checker?
- rattray 8y ago
  Have you tried PyRight? It claims to be much better than mypy.
- joshuamorton 8y ago
  What are the issues with mypy + python compared to say, Java?
akubera 8y ago
As far as I can tell, Pyright is designed only for the VSCode plugin? Or at least is a typescript project that parses and analyzes python code, so if you're using that stack already it may be a good choice, but otherwise it's more stuff to install. Actually, I'll say people with python projects shouldn't "target" it because it's not a pure python stack, and it would add friction/overhead for people who don't already have npm installed. It's just for people coding python with the VSCode editor. As I mentioned in a comment to that post, I used pyright for a few minutes and was impressed. You get red-squigglies under unexpected-type & no-such method errors, and I saw green squiggly under a "value may not be set" in a function like: def foo(x: int): if x > 4: y = 1 return y The immediate visual feedback is great. The dependency on typescript is not. Searching VSCode, I see no plugins for mypy & PyType, and the pyre-vscode plugin requires pyre-check to be installed, and a .pyre_configuration file in the directory? All I know is I couldn't get it to do anything, but pyright worked out of the box with no effort. I haven't used this PyType project, but it looks like it competes with mypy. I like that it, too, uses your setup.cfg file for configuration (I'm all about single-file configuration projects). Someone else will have to speak to the differences between them. I'm sure they have the same functionality, so the differences will likely be in the specifics like what the error messages look like and how easy they are to configure. If you contribute to various python projects, I supposed it wouldn't hurt to have them both installed. As for which to choose, mypy is Guido's project (or at least the one he's associated with) and until another is clearly superior, you can be pretty certain it will track changes in the python language closely for a while. I use mypy & flake8 for "static checking". My question is: are there any plugins that show error-indicator squigglies for pep8 violations?
- rattray 8y ago
  Is pyright's dependency on node really that bad? Many projects need to have Node anyway, and/or use Docker or another tool to dictate which version of Python they're using.
  - akubera 8y ago
    As with everything, depends on the audience. If working on something web-related or has an obvious need for javascript, then yeah, node can be an assumed dependency (actually probably preferred because I'd imagine you get better integration with the rest of your project than with unittest/pytest). But if it's a pure-python library that has nothing to do with javascript/typescript I think it's too much to ask someone to be sure to install proper versions of node+npm+typescript+whatever-else so your `python setup.py test` runs correctly. The same would apply to a javascript project that had dependency on python3.6 for their type checker. Many projects need node, but not all; I don't know any which require docker. I want to be clear: with pyright, it's not bad! I think it's the right way to do the LSP plugin: no dependency on the current python version (am I using the python in the venv? or ~/.local/bin? or /usr/bin/?) and great integration with the editor. If it's a large project that will benefit from "5x faster" typechecking than mypy, then yeah, it's probably worth the dependencies. If you have a 5-file python package I found on pypi that I want to contribute to, but there's nonstandard hoops to jump through to get `python setup.py test` working properly, I would have preferred you made a different call in this regard. I'm glad we have choices and it's not mono-culture.
nerdponx 8y ago
Or MyPy?
- bvaldivielso 8y ago
  mypy, although under the umbrella of the python foundation, is (or used to be, anyway) primarily developed by Dropbox
liteye 8y ago
From the readme of Pytype, it's doing type inference instead of type checking. Although I don't know how accurate it is, type inference is much harder than type checking, especially on a language designed with dynamic typing in mind
- lrem 8y ago
  It's pretty good. It's been designed to deal with the humongous legacy code base in Google.
bshipp 8y ago
I'm not an expert coder by any stretch of the imagination, but the linter built into Pycharm does a decent job of identifying the most egregious typing errors, IMHO. I think a lot of it really comes down to how much domain knowledge you have with respect to the problem you're trying to solve. I tend to have to process a lot of data from unknown sources, with unknown and inconsistent encoding. Most errors either show up immediately in Pycharm when I'm coding, within the first few moments of running the program, or two weeks later when it encounters a bizarre batch of records in the 15 millionth row of the database I'm processing or some strange network error that I neglected to foresee. I personally don't see how compile time typechecking would make any difference to that latter set of errors (which are solely due to my lack of foresight on all the weird ways people find to handle data), and the first two sets of errors are usually resolved in the testing phase of initial program debugging.

CloudYeller 8y ago

Not to be a total smartass, but if your Python codebase is not that big yet, then the correct answer is none of the above- rewrite in a compiled language if you find the lack of static checks disturbing. I have been using "type checked" python for a year and let me tell you, it is not even 10% as good as having a real compiler. Python type checkers are not even close to 100% accuracy. If you're going to use a python type checker, use the one that has the most dev resources behind it. Which probably means, whichever company has the most internal python code, which is probably Google. So pytype. But bear in mind, these things are only sensible when you've written so much python code that it's too late to rewrite in a better language. If you're in that situation, even though these checkers are far from perfect, they are a massive improvement over plain python.

melling 8y ago
I only asked for an evaluation of the current Python checkers, not a philosophy lesson. In theory there's no difference between theory and practice, but in practice there is. So, in practice which is the best current Python type checker?
rattray 8y ago
Have you tried PyRight? It claims to be much better than mypy.
joshuamorton 8y ago
What are the issues with mypy + python compared to say, Java?

akubera 8y ago

As far as I can tell, Pyright is designed only for the VSCode plugin? Or at least is a typescript project that parses and analyzes python code, so if you're using that stack already it may be a good choice, but otherwise it's more stuff to install. Actually, I'll say people with python projects shouldn't "target" it because it's not a pure python stack, and it would add friction/overhead for people who don't already have npm installed. It's just for people coding python with the VSCode editor. As I mentioned in a comment to that post, I used pyright for a few minutes and was impressed. You get red-squigglies under unexpected-type & no-such method errors, and I saw green squiggly under a "value may not be set" in a function like: def foo(x: int): if x > 4: y = 1 return y The immediate visual feedback is great. The dependency on typescript is not. Searching VSCode, I see no plugins for mypy & PyType, and the pyre-vscode plugin requires pyre-check to be installed, and a .pyre_configuration file in the directory? All I know is I couldn't get it to do anything, but pyright worked out of the box with no effort. I haven't used this PyType project, but it looks like it competes with mypy. I like that it, too, uses your setup.cfg file for configuration (I'm all about single-file configuration projects). Someone else will have to speak to the differences between them. I'm sure they have the same functionality, so the differences will likely be in the specifics like what the error messages look like and how easy they are to configure. If you contribute to various python projects, I supposed it wouldn't hurt to have them both installed. As for which to choose, mypy is Guido's project (or at least the one he's associated with) and until another is clearly superior, you can be pretty certain it will track changes in the python language closely for a while. I use mypy & flake8 for "static checking". My question is: are there any plugins that show error-indicator squigglies for pep8 violations?

rattray 8y ago
Is pyright's dependency on node really that bad? Many projects need to have Node anyway, and/or use Docker or another tool to dictate which version of Python they're using.
- akubera 8y ago
  As with everything, depends on the audience. If working on something web-related or has an obvious need for javascript, then yeah, node can be an assumed dependency (actually probably preferred because I'd imagine you get better integration with the rest of your project than with unittest/pytest). But if it's a pure-python library that has nothing to do with javascript/typescript I think it's too much to ask someone to be sure to install proper versions of node+npm+typescript+whatever-else so your `python setup.py test` runs correctly. The same would apply to a javascript project that had dependency on python3.6 for their type checker. Many projects need node, but not all; I don't know any which require docker. I want to be clear: with pyright, it's not bad! I think it's the right way to do the LSP plugin: no dependency on the current python version (am I using the python in the venv? or ~/.local/bin? or /usr/bin/?) and great integration with the editor. If it's a large project that will benefit from "5x faster" typechecking than mypy, then yeah, it's probably worth the dependencies. If you have a 5-file python package I found on pypi that I want to contribute to, but there's nonstandard hoops to jump through to get `python setup.py test` working properly, I would have preferred you made a different call in this regard. I'm glad we have choices and it's not mono-culture.

nerdponx 8y ago

Or MyPy?

bvaldivielso 8y ago
mypy, although under the umbrella of the python foundation, is (or used to be, anyway) primarily developed by Dropbox

liteye 8y ago

From the readme of Pytype, it's doing type inference instead of type checking. Although I don't know how accurate it is, type inference is much harder than type checking, especially on a language designed with dynamic typing in mind

lrem 8y ago
It's pretty good. It's been designed to deal with the humongous legacy code base in Google.

bshipp 8y ago

I'm not an expert coder by any stretch of the imagination, but the linter built into Pycharm does a decent job of identifying the most egregious typing errors, IMHO. I think a lot of it really comes down to how much domain knowledge you have with respect to the problem you're trying to solve. I tend to have to process a lot of data from unknown sources, with unknown and inconsistent encoding. Most errors either show up immediately in Pycharm when I'm coding, within the first few moments of running the program, or two weeks later when it encounters a bizarre batch of records in the 15 millionth row of the database I'm processing or some strange network error that I neglected to foresee. I personally don't see how compile time typechecking would make any difference to that latter set of errors (which are solely due to my lack of foresight on all the weird ways people find to handle data), and the first two sets of errors are usually resolved in the testing phase of initial program debugging.