Pyre vs mypy about pyre-check

[dkgi]

Thanks, though this does not really answer what's wrong with contributing to mypy, for example helping to make it faster. There seems to be no reason why your (very cool!) static analysis tools wouldn't work with any type checker. After all they only care about the end result: the resolved types of functions and variables.

@ze-phyr-us: there's nothing wrong with contributing to mypy ;) We decided not to because for two main reasons:

1. we believe there are fundamental limitations to what you can achieve in terms of performance in a tool written in Python. I'm sure it's possible replicate the lock free shared-memory / multiprocessing architecture in Python but that leads to
2. we do have a lot of the infrastructure for this already in place from the Hack type checker. On top of the parallelization we can also reuse parts of the deeper static analysis we're running on our PHP codebase that we haven't been able to open source before.

[vitawasalreadytaken]

Thanks, though this does not really answer what's wrong with contributing to mypy, for example helping to make it faster. There seems to be no reason why your (very cool!) static analysis tools wouldn't work with any type checker. After all they only care about the end result: the resolved types of functions and variables.

Don't get me wrong – I am glad that gradual typing is gaining so much traction in the Python world. But as I understand it writing a good type checker for Python is a massive undertaking – judging by the number of issues Mypy has and which we run into almost daily when using it at work. So clearly your decision to write your own was not taken lightly, and I am wondering why you decided Mypy wasn't worth the effort.

[gnprice]

I'm not affiliated with the Pyre team, but you may find these comments helpful from one of them: https://news.ycombinator.com/item?id=17048682

To summarize: the "overriding concern" was

We are building deeper semantic static analysis tools on top of Pyre. We've built some of these tools for Hack/PHP already, so following the Hack type checker's architecture is the best way for us to achieve this.

[dkgi]

I think @phooji's comment on Hackernews captures the basic motivation. He also gave a talk at PyCon providing more context around the direction we're taking here: https://www.youtube.com/watch?v=hWV8t494N88