Hacker News new | ask | show | jobs
by _gtly 1186 days ago
Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": https://dl.acm.org/doi/pdf/10.1145/3578360.3580275

"Currently, there are several Python features that Codon does not support. They mainly consist of runtime polymorphism, runtime reflection and type manipulation (e.g., dynamic method table modification, dynamic addition of class members, metaclasses, and class decorators). There are also gaps in the standard Python library coverage. While Codon ships with Python interoperability as a workaround to some of these limitations, future work is planned to expand the amount of Pythonic code immediately compatible with the framework by adding features such as runtime polymorphism and by implementing better interoperability with the existing Python libraries. Finally, we plan to increase the standard library coverage, as well as extend syntax configurability for custom DSLs."

4 comments

Ye well if you remove the dynamic feutures of a dynamic language it gets fast. It would be really impressive of they can achieve those feutures with the sameish speed.
I dont necessarily need all that dynamism though, and would happily use a Python subset that removed some stuff (and forced type hinting) in exchange for better compilation.

Yes there are already subsets like this, but its not as helpful if it isnt standard.

Depends of the work you have to do.

If you code a website, fast api and django, the two most popular framework to do so, heavily rely on them to make you productive.

If you code a website, your speed issues probably come from the database layer. Not your Python.
What are you doing to your database? Lol

Most databases I’ve dealt with will happily outstrip Python for a good chunk of the common queries.

Measuring database speed is ultimately I/O bound, measuring a language's speed is typically CPU-bound.
For sure, but django for instance is really good at turning something that ought to be one query into N+1 queries.
Starlark comes to mind, but that's probably too limited.
I'm sure this is a great project worthy of HN front page reporting but if it can't run python generally,it ain't python.
Isn’t it “self”, really? [1]

Assume your python program is fully static and well behaved from a compiler perspective. JIT compile it, and observe what it does, so that you can invalidate the compiled code and re-JIT it if it does something overly dynamic.

Incidentally, what JVM did. (I’m sure now it’s been tweaked beyond recognition)

[1] https://bibliography.selflanguage.org/pics.html

I wonder what experienced Common Lisp compiler devs could accomplish if they turned their attention to Python.
no thanks, julia is a nicer matlab. python is a proper general purpose language.
Julia is not a proper general purpose programming language, because it has one-based array indexing?
There is an implementation of Python in Common Lisp https://clpython.common-lisp.dev/ but I think you probably mean some more lower-level thing
I do: I mean some people with experience making Common Lisp implementations (SBCL, maybe) getting an idea and implementing Python with the same basic concepts they used to implement a Common Lisp compiler.