SPy: An interpreter and compiler for a fast statically typed variant of Python

Re:SPy: An interpreter and compiler for a fast statically ty... by graemep on Wednesday November 05, 2025 @07:38AM (#45822207)

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.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by antocuni on Wednesday November 05, 2025 @08:15AM (#45822497)

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.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by graemep on Wednesday November 05, 2025 @09:03AM (#45822937)

Thanks for the answer. I have to admit I missed the implications of embedding libpython. Sounds great.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by rurban on Wednesday November 05, 2025 @08:01AM (#45822398)

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.

A type is a contract, not a hint!

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by setopt on Wednesday November 05, 2025 @08:30AM (#45822617)

> A type is a contract, not a hint!

In Python it is a hint.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by rurban on Wednesday November 05, 2025 @08:40AM (#45822709)

Exactly. That was their worst mistake ever

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by setopt on Wednesday November 05, 2025 @02:28PM (#45826813)

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.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by almostgotcaught on Thursday November 06, 2025 @01:13AM (#45832039)

Never gonna happen - the fundamental premise of the language is duck typing.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by setopt on Thursday November 06, 2025 @04:51AM (#45833356)

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.

[ Parent | on HN ]

Re:SPy: An interpreter and compiler for a fast statically ty... by sevensor on Thursday November 06, 2025 @05:17AM (#45833538)

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.

[ Parent | on HN ]