I work on a monorepo and MyPy and Flake8 was such a PITA at first but after you use it for a while, you really see the value of type checking. Makes unit testing better and the code more robust in general. MyPy is seriously a great tool, especially with pydoc enforcements.
Mypy 1.6
11–20 of 114 posts
Re: Mypy 1.6
#12Earlier quoted context omitted.
At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.
It is a downgrade in language features, there is always PyPy.
Re: Mypy 1.6
#13Earlier quoted context omitted.
At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.
It is a downgrade in language features, there is always PyPy.
Re: Mypy 1.6
#14Re: Mypy 1.6
#15Earlier quoted context omitted.
It is a downgrade in language features, there is always PyPy.
In fairness, if you are choosing a language based on language features, you are not going to choose Python either.
Re: Mypy 1.6
#16Earlier quoted context omitted.
It is a downgrade in language features, there is always PyPy.
In fairness, if you are choosing a language based on language features, you are not going to choose Python either.
Also, what is Python lacking that other languages have? It's expressive and fast to develop, and with type hints and linters, reasonably robust.
My main complaint is performance, but I'll take the speed to write most days.
Re: Mypy 1.6
#17Earlier quoted context omitted.
It is a downgrade in language features, there is always PyPy.
If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?
And if that isn't enough, the answer is OCaml, F#, D, C#, Java, Scala, Haskell, Kotlin, C++,... definitely not going from horse to donkey in language features.
Re: Mypy 1.6
#18Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside. [0]: https://github.com/microsoft/pyright
They all seem to have slightly different approaches and features, but it's hard to decide which is best for the job.
Re: Mypy 1.6
#19A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster (Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own.
I've generally liked Pyright (as a side note, they have super responsive maintainers - ask a question on their GH, and they usually answer within a few hours), but I've been wondering if I am missing out with Mypy.
Re: Mypy 1.6
#20Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside. [0]: https://github.com/microsoft/pyright
Is there any in depth comparison of mypy, pytype, pyright and pyre yet? They all seem to have slightly different approaches and features, but it's hard to decide which is best for the job.
https://github.com/microsoft/pyright/blob/main/docs/mypy-com...