Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

antocuni.eu

Post reply on HN
Print view View original

121–130 of 133 posts

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

#121

Post by setopt »

almostgotcaught wrote: post #113
setopt wrote: post #91

Earlier quoted context omitted.

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.

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

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.

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

#122

Post by sevensor »

setopt wrote: post #121
almostgotcaught wrote: post #113

Earlier quoted context omitted.

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

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.

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

#123

Post by codethief »

oofbey wrote: post #104
ic_fly2 wrote: post #75

If in the end we can just have .spy on some files that have performance critical functions in them and the rest is just normal python, this could be down right amazing. We recently swapped out mypyc optimised module for a rust implementation to get a 2-6x speed up, and not having to do that would be great.

+1 this. Also, when I read about the language features which make Python intrinsically slow, generally I think "I never use that." e.g. operator overloading meaning you need to do all these pointer dereferences just to add two numbers together. Yes, I get that pytorch and numpy rely critically on these. But it makes me wonder... Could you disable these language features on a module-by-module basis? That is, declare "…

It probably would but it'd likely not be trivial. Because how do you recognize monkey-patching in a dynamically typed language? I can think of many edge cases here.

That being said, you might be interested in https://docs.python.org/3/reference/datamodel.html#slots

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

#124

Post by robert-brown »

thomasmg wrote: post #92
PaulHoule wrote: post #70

Earlier quoted context omitted.

One of the standard architectures for complex applications is to put together a scripting language and an systems programming language. You can either look at the scripting language as primary with the systems language used for performance or hardware interfacing or you can look at the systems language being primary and the scripting being used around the edges. The model of having a closely related scripting and sys…

Yes, there are quite many real-world cases of this architecure. But, wouldn't it be better it the same language (more or less) can be used for both? I don't think such a language exists currently, but I think it would be a nice goal.

Common Lisp

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

#125

Post by nylonstrung »

netbioserror wrote: post #56
ajb wrote: post #45

It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…

Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…

Nim honestly seems like such a perfect general purpose language, I wish it was invented 10 years ago or that the adoption drastically increases though because the lack of ecosystem makes it tough rn

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

#126

Post by nylonstrung »

PaulHoule wrote: post #70
ajb wrote: post #45

It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…

One of the standard architectures for complex applications is to put together a scripting language and an systems programming language. You can either look at the scripting language as primary with the systems language used for performance or hardware interfacing or you can look at the systems language being primary and the scripting being used around the edges. The model of having a closely related scripting and sys…

The most interesting pairing I've been thinking about is Rust + RustPython

It's a full python interpreter implemented in Rust. Python has many advantages as a scripting language but the problem is you inherit all the packaging and deployment challenges unlike with Lua for example

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

#127

Post by nylonstrung »

falcor84 wrote: post #6

This seems to be going for a somewhat similar goal to Mojo [0] - anyone here who used both and is willing to offer a comparison? [0] https://www.modular.com/mojo

Mojo is such an interesting project but it's disappointing they pivoted so hard to focusing on GPU kernel programming and seemingly abandoned the objective of a general purpose python alternative

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

#128

Post by nylonstrung »

leobuskin wrote: post #13
srean wrote: post #5

If you want different parts of your code to be a statically typed Python lookalike Cython is a mature option

Yes, it's mature, but you (and your potential audience) basically need to learn a new language, a lot of quirks and "weird" (I'd even say counter-intuitive) nuances, and it's also significantly less readable in comparison with strict and typed Python. Even its modern syntax doesn't click immediately (also performance wise the new syntax somehow is a bit slower in my tests)

It does seems very much like "worst of both worlds" in that these nuances make it harder to write than a language like Go while still being drastically less performant

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

#129

Post by nylonstrung »

ranger_danger wrote: post #64

I'm still looking for a python-ish (at least the syntax) embeddable library for C that is easy to include in a project, a library that does not have its own build system with dozens of files... but I don't think one exists.

RustPython seems like the fulfillment of this for Rust but unfortunately haven't seen an equivalent for C

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

#130

Post by nylonstrung »

This is really promising and I hope it succeeds. It does seem like the most well conceived attempt at this yet and I think the network effects of Python (especially with LLM codegen) are so strong that something like this has to gain adoption

So far the options like AOT python simply don't present enough performance improvement relative to the complexity they introduce

Post reply on HN