The problem with this is that the main value of Python is its ecosystem. SPy aims to be able to import Python libraries, but also not implement all Python features. If you are not 100% compatible how can you reliably import libraries?
SPy seems most likely to be more likely to be appealing as a more Pythonic alternative to Cython rather than a Python replacement.
hello, author of the blog post and author of SPy here.
> how can you reliably import libraries?
the blog post specifies it but probably not in great level of detail. Calling python libs from spy will go through libpython.so (so essentially we will embed CPython). So CPython will import the library, and there will be a SPy<=>CPython interop layer to convert/proxy objects on the two worlds.
I did a similar project, a typed perl. cperl. I could import most the modules, and did add types to some of the important modules. Eg testing was 2x faster. I needed typing patches for about 10% for most CPAN packages.
I agree. I use Beartype to get runtime type checks, but it shouldn’t be necessary. Some support for type checking, whether at byte compile time or runtime, should land upstream.
Either you add type hints to your function and should expect it to be type checked, or you don’t add type hints and remain free to use duck typing as you want.
But not receiving as much as a warning when you violate type hints is the worst of both worlds.
Duck typing isn’t completely incompatible with type checking btw. Haskells type classes are an elegant solution to that, for example.
Python protocols work great for duck typing as well. You can specify exactly how an object has to quack without constraining it to an avian family tree.
SPy seems most likely to be more likely to be appealing as a more Pythonic alternative to Cython rather than a Python replacement.