[HN Gopher] LPython: Novel, Fast, Retargetable Python Compiler (...
___________________________________________________________________
LPython: Novel, Fast, Retargetable Python Compiler (2023)
Author : luismedel
Score : 45 points
Date : 2025-05-13 09:01 UTC (3 days ago)
(HTM) web link (lpython.org)
(TXT) w3m dump (lpython.org)
| brudgers wrote:
| The repository appears to be active,
| https://github.com/lcompilers/lpython
| nathan_compton wrote:
| Very neat but what an Albatross Python is, especially in the AI
| era. It is clearly the best language to choose for many
| applications given the network effects and the fact that AI can
| program it so effectively, but I really wish we weren't locked
| into it. So many better, more fun, more tight, languages out
| there.
|
| And all this effort to eek out performance. Get off my lawn etc.
| throwaway7783 wrote:
| What's your personal favorite better, fun, tight language?
| sgammon wrote:
| Kotlin
| nathan_compton wrote:
| I love programming in Scheme. I played with Nim recently and
| appreciated the type system. I also enjoy Common Lisp. Heck,
| I ever prefer Java! Haskell, Ocaml, Julia! I'd rather program
| in any of them.
| raffraffraff wrote:
| Most of the time, Python's biggest issue isn't performance,
| it's the nightmare of trying to distribute it. If you want to
| merely run a python program you need to be educated in "python
| DevOps", or you'll get people gasping and saying "FFS, why
| don't you just create an env and activate it and pip install to
| it then make your own flipping shortcut to a script that
| activates that env and runs your code, you moron, Jeeeeeesus."
| dumah wrote:
| PEP-723 solves this nicely.
|
| https://peps.python.org/pep-0723/
|
| https://news.ycombinator.com/item?id=43500124
| gjvc wrote:
| that the "activate it" part gets any airtime really pisses me
| off. that has all to do with bash and zero to do with python.
| the "activate" script should never have seen the light of
| day.
|
| include a bin/run-python wrapper script in your project, and
| have that set environment variables and call the
| .venv/bin/python binary. done.
|
| yes, i realise in replying to this comment i'm admitting that
| i'm part of the problem exactly described, but the "activate"
| script has caused more confusion in the long run than is
| worthwhile and the "running from a .venv/" directory could
| have been a much smaller problem instead of the wind-tunnel
| it has become.
| terlisimo wrote:
| why not solve it with bash then, just put
|
| #!/path/to/your/venv/bin/python
|
| as first the line of your script, done/done
| gjvc wrote:
| That is obviously not what I meant by "solving it with
| bash" and well you know it.
|
| First, one often needs to set PYTHONPATH etc, and this is
| best done near the point of execution, in a wrapper
| script and not wangling around in ~/.bash_profile where
| it gets forgotten, and is not project-specific.
|
| Secondly, and more importantly, your suggestion assumes
| the venv lives in a fixed location. This is unlikely to
| be the case.[1] What is preferable is something which is
| independent of filesystem location. The bin/run-python
| script is able to find its location on the filesystem,
| and the location of the venv relative to it.
|
| [1] You might have a custom python distribution with a
| bunch of modules installed into a well-known location and
| therefore using that for the python in your application
| is a reasonable solution, but that is not what we are
| talking about here.
| theanonymousone wrote:
| Hopefully PEP-723 and uv will alleviate this.
| lesser23 wrote:
| Having been around for a long time I liken it to PERL. Post-
| PERL it also looks a lot like Ruby. I remember everything being
| re-written in Ruby. Yet PERL still stands!
|
| Anyway, Python is a nice language for small-ish (< 1000 lines
| or so) projects. It starts to get very unruly after that and
| without a type system of any kind your brain becomes the type
| system... and the compiler. MyPy tries it's best but it really
| isn't sufficient and requires developer buy-in...hard to get in
| a language so well designed for throw-away code.
|
| Python 3's syntax is actually quite nice and you can write some
| very expressive code in it. My opinion, of course, but I also
| find it to be one of the "lowest common denominator" languages
| like Go. Python doesn't require much to get started and it's
| syntax and semantics are relatively easy for even a mediocre
| programmer to understand. Of course it has a terrible (mostly
| non-existent ABI) that relies on "consenting adults" as the
| contract and an awful package system. Yet another reason it's
| really only practical for (relatively) small projects.
|
| Rarely is anything in Python about raw performance - imo. Of
| the things that are (NumPy, Pandas, various ML libraries) they
| call down to C handle most of it. For things that require true
| parallelism it's not uncommon to see `exec` calls to binaries.
| That being said in a lot of places (FastAPI based applications,
| etc) you can get quite a lot of perf out of Python before it
| becomes a problem.
|
| However, what makes it super nice is how easy it is to hack
| something together in it. As it turns out most of ML is just
| hacking things together in a few files or a Jupyter notebook.
| What a perfect language for such purpose. This is not unlike
| PERL. I still remember all the random PERL scripts I hacked
| together for various tasks because it was _so simple_. It is no
| wonder it is as popular as it is.
| sgammon wrote:
| How does this compare to GraalPy? Why create something new when
| GraalPy can already build native programs?
| theanonymousone wrote:
| I'm following them since their first mention in HN in 2023,
| particularly for Wasm support in compilation. Still not much
| output, unfortunately.
___________________________________________________________________
(page generated 2025-05-16 23:01 UTC)