Hacker News Reader

Comment by adsharma | Hacker News Reader

++spy ethos and ideas

But why limit to an interpreter? Translate to other excellent compiled languages and benefit from the optimization work there.

Giving up on C-API and the dynamic parts of python that 1% of the people use is a good trade-off.

In the age of cursor and windsurf it's not hard to auto replace incompatible code with something that works in the static-py ecosystem.

Would love to participate in an effort to standardize such a subset.

View on HN

I'd imagine a lot of packages that you may want to use make deep use of some of these obscure features. So much magical "it just works" of Django is surely various kinds of deep introspection.

Not sure an AI can fix it yet. It's not just adding type annotations.

The position I take is that such obscure code in the guts of a popular package could be slowing down large amounts of deployed code elsewhere. If such code must exist, it should be marked as special (like how Cython does it).

Beyond adding type annotations, there are other important problems to solve when translating python to rust (the most popular path in py2many so far).

  * Translating inheritance -> traits
  * Translating exceptions -> Result<T>
  * Handling incompatible pattern matching

This is why I've urged FastAPI and pydantic maintainers to give up on BaseModel and use fquery.pydantic/fquery.sqlmodel decorators. They translate much better.

There is a compiler detailed in the page on the link;

> 3. We have a compiler for deployment and performance. The interpreter and the compiler are guaranteed to produce the exact same results at runtime.

Where is it? Would love to compare the approach to py2many.

https://github.com/spylang/spy

Py2many would fail to compile dynamic code whereas spy runs it through the interpreter.

Otherwise the internal structure looks similar. Py2many has been around for 10+ years under previous names and has significant test coverage.

Reply on news.ycombinator.com