

-
MyPy isn’t the only checker of course, there’s also Microsoft’s Pyright, among others. Pyright is fast and natively integrated in Microsoft’s Pylance VSCode extension, so these days I use Pyright’s type checking in real time even when I can’t be bothered to set up MyPy (no difficult, just not important for, say, <1000 line scripts).
https://github.com/microsoft/pyright
https://marketplace.visualstudio.com/items?itemName=ms-pytho...
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
It reminds me of this 5 year old bug in mypy: "int is not a Number?" [1].
[1]: https://github.com/python/mypy/issues/3186
-
-
> warnings of IDEs are simple to ignore
This is unusual. In my experience, of codebases I have worked with or have seen, when there are type hints, there are almost all perfectly correct.
Also, you can setup the CI to check also for IDE warnings. For example, we use this script for PyCharm: https://github.com/rwth-i6/returnn/blob/master/tests/pycharm...
The test for PyCharm inspections only passes when there are no warnings.
Although, I have to admit, we explicitly exclude type warnings because here we have a couple of false positives. So in this respect, it actually agrees with the article.
But then we also do code review and there we are strict about having it all correct.
Yes, I see the argument of the article that the typing in Python is not perfect and you can easily fool it if you want, so you cannot 100% trust the types. But given good standard practice, it will only rarely happen that the type is not as expected and typing helps a lot. And IDE type warnings, or mypy checks still are useful tools and catch bugs for you, just not maybe 100% of all typing bugs but still maybe 80% of them or so.
> Isn’t it better to detect at least some errors than to detect none at all?
-
Nim
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
> What I want is this: Some language that’s as easy to use as Python and it should be compiled and with good static typing...
Well, there's always Nim. [0]
> ...but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops?
Eh, there's Nimscript? [1]
0. https://nim-lang.org/
-
cinder
Cinder is Meta's internal performance-oriented production version of CPython. (by facebookincubator)
This article captures a lot of the rationale behind why we're building Static Python within Cinder: https://github.com/facebookincubator/cinder#static-python
-
-
Nutrient
Nutrient - The #1 PDF SDK Library. Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.
-
-
-
-
https://github.com/python/typeshed also provides community maintained stub packages for packages that are lacking upstream type hints
-
The flawed nature of JS, yet remaining the only one supported by browsers, has indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more.
There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python
-
(I've chopped it down a bit to emphasise the important bits)
But then I looked at upstream and I notice they've added type annotations, which do greatly improve things:
https://github.com/urllib3/urllib3/blob/e16beb210c03c6f5ce4e...
def _new_conn(self) -> socket.socket: