ruby-implementations VS mypy

Fascinating, does the project aspire to become compatible with MRI Ruby? Also how many active Ruby implementations do we have so far?

Edit: Found this, https://github.com/codicoscepticos/ruby-implementations?tab=...

I see the point to make a parallel with HipHop, but here YJIT is directly integrated in CRuby, the main implementation of the language, and it’s just a matter of command line flag whether you enable or disable it — at least from what I remember that I red.

From what I remember, HipHop was distributed in a different toolchain than the vanilla PHP interpreter. Ruby also have other interpreters available by the way: https://github.com/codicoscepticos/ruby-implementations

To expand on this, you could be maintaining a list of Cats, call a function which accepts a list of Animals, and that function could append a Dog without causing a type error.

https://github.com/python/mypy/issues/4976 is an interesting discussion on this in Python: should a TypedDict be allowed where a dict argument is accepted? The basic consensus is no, because then one could modify the dict, adding keys that wouldn't be allowed in the specific TypedDict.

But this means that often you have to do cast(dict, my_typed_dict) to be able to interop with third party libraries that (quite naturally) believed that by typing their arguments as accepting a dict, they'd be accepting all dict-like things.

Mypy:

Hynek Schlawack, a well-known Pythonista and open source contributor, has recommended not to run mypy as part of your pre-commit workflows. And Shantanu Jain, a CPython core developer and mypy maintainer, has an excellent write-up of some of the gotchas that come with running mypy as a pre-commit hook. By default, mypy runs in an isolated environment, meaning it won't have access to your project's virtual environment and therefore won't be able to fully analyze type hints when your code makes use of dependencies. Additionally, pre-commit hooks only pass the changed/staged files by default, whereas mypy needs to see the entire repository to function correctly. I've also noticed nesting your code under other folders (like my backend/ directory) can also cause problems.

No named tuple support is a deal-breaker for some projects. This is directly from their GitHub issues comments[1]:

> Duplicate of #5613, still low priority, better use dataclasses, as suggested above.

1. https://github.com/python/mypy/issues/5944#issuecomment-4412...

disclaimer: I don't work on big codebases.

Pylance with pyright[0] while developing (with strict mode) and mypy[1] with pre-commit and CI.

Previously, I had to rely on pyright in pre-commit and CI for a while because mypy didn’t support PEP 695 until its 1.11 release in July.

[0] -- https://github.com/microsoft/pyright

[1] -- https://github.com/python/mypy

If you want to learn more about Protocols and type hinting in Python, check out the official Python documentation on the typing module, or explore advanced static type checking tools like mypy.

https://github.com/python/mypy

> Python itself doesn't do that

The type syntax is python. MyPy is part of Python. It's maintained by the python foundation. Mypy is not part of CPython because modularity is good, the same way that ANSI C doesn't compile anything, that's what gcc, clang, etc are for.

Mojo is literally exactly the same way, the types are optional, and the tooling handles type checking and compilation.