While you're at it fix Python's crippled lambdas and ...
What's wrong with Ellipsis?
RustPython: A Python Interpreter Written in Rust
41–50 of 75 posts
Re: RustPython: A Python Interpreter Written in Rust
#42Does this have faster startup times than cpython?
Every time I want to rewrite a shell function in python, I always hesitate due to the slow startup.
Re: RustPython: A Python Interpreter Written in Rust
#43I don't understand how it's possible that we just randomly come across a project that just casually implements a Python interpreter in Rust. Don't these things take a massive amount of effort? Wouldn't this be making waves much earlier in its development process? I feel the same way about Ruff, for example. One day it was "black all the things" and the next it's "btw we just reimplemented the entire Python formatting…
> Don't these things take a massive amount of effort? Yes, RustPython has been in development since at least 2018. > Wouldn't this be making waves much earlier in its development process? It's been posted on HN several times before: https://hn.algolia.com/?q=rustpython
Ah ok, it's at least comforting to know that I missed it, rather than there are superhuman developers that crank these projects out in an afternoon.
Re: RustPython: A Python Interpreter Written in Rust
#44I don't understand how it's possible that we just randomly come across a project that just casually implements a Python interpreter in Rust. Don't these things take a massive amount of effort? Wouldn't this be making waves much earlier in its development process? I feel the same way about Ruff, for example. One day it was "black all the things" and the next it's "btw we just reimplemented the entire Python formatting…
For me the "uv" manager has changed my Python experience because: (1) it has a correct resolver whereas "pip" certainly doesn't and I'm not sure about poetry, (2) it is crazy fast, (3) "uv" is just a binary which I can pip into my system. (3) is important because if it was written in Javascript or Java or Python or .NET or many other languages I'd have to learn something about the runtimes of those environment to get…
I'm really looking forward to uv being a drop-in replacement for Poetry. I don't know if that's what they're planning to do, though. Does it currently have all the niceties of Poetry (dependency management, locks, building wheels, etc?).
Re: RustPython: A Python Interpreter Written in Rust
#45Earlier quoted context omitted.
The complete semantics of Python object lifetime are expensive to implement in a compatible manner without a GIL. Jython got around this by not doing it, making it not fully compatible (yes, people do depend on objects being eagerly freed), just using the JVM GC instead. If you do want full compatibility, the choice is between single-threaded performance and parallelism.
> yes, people do depend on objects being eagerly freed I get that this must be one aspect of the necessity of the GIL but I mean, C++ also has eager free behavior due to RAII and threads are working fine there, as long as you know what you're doing. Perhaps that's the rub though, it's pretty easy to crash/deadlock in C++ and we blame the programmer rather than the language.
Idiomatic C++ relies much more heavily on ownership and not so much on refcounting. If you have code that's a rat's nest of shared_ptr, it's going to perform very poorly in a multithreaded environment. But that's why any C++ guru will tell you to not make a rat's nest of shared_ptr. When refcounting is commonly used in C++, like with GUI code or dependency graphs of network requests, it's usually in non-performance-critical sections.
In Python, by contrast, all variables default to object references, and so nearly everything you do involves updating a refcount.
Re: RustPython: A Python Interpreter Written in Rust
#46Earlier quoted context omitted.
For me the "uv" manager has changed my Python experience because: (1) it has a correct resolver whereas "pip" certainly doesn't and I'm not sure about poetry, (2) it is crazy fast, (3) "uv" is just a binary which I can pip into my system. (3) is important because if it was written in Javascript or Java or Python or .NET or many other languages I'd have to learn something about the runtimes of those environment to get…
I'm really looking forward to uv being a drop-in replacement for Poetry. I don't know if that's what they're planning to do, though. Does it currently have all the niceties of Poetry (dependency management, locks, building wheels, etc?).
Isn't it Rye ? (https://rye.astral.sh)
"Rye supports two systems to manage dependencies: uv and pip-tools. It currently defaults to uv"
I've been evaluating it lately and it has pretty much the same CLI commands as Poetry except it's faster and comes with complete Python interpreter management (which is to me the real killer feature as I don't really care about speed of dependency resolution, but I do care about the DX).
Re: RustPython: A Python Interpreter Written in Rust
#47Earlier quoted context omitted.
Hadn't thought about Jython for a while. Whatever happened to that?
One of the casualties of the Python 2 => Python 3 debacle, it seems.
It's special-purpose, and always has been. You use Jython when you want to embed a Python-like interpreter into a Java program. Usually when you do so, you're scripting the objects of the Java program, and don't need or want to import arbitrary Python packages. Indeed, that's often the whole point of Jython - the system designer wants a language that's familiar to Python programmers, while also being able to control the environment that those Python scripts can access.
This is not different from the Python 2 days. Jython has always had subtly different semantics from Python (eg. it uses Java strings instead of Python ones, there's no C API, it relies on the Java GC so no eager free), so many common libraries wouldn't work with it. Just try to run NumPy on Jython - you can't, despite the same developer authoring both Jython and NumPy's predecessor.
Re: RustPython: A Python Interpreter Written in Rust
#48Earlier quoted context omitted.
> Don't these things take a massive amount of effort? Yes, RustPython has been in development since at least 2018. > Wouldn't this be making waves much earlier in its development process? It's been posted on HN several times before: https://hn.algolia.com/?q=rustpython
Ah ok, it's at least comforting to know that I missed it, rather than there are superhuman developers that crank these projects out in an afternoon.
I’d wager they don’t hit major spread from opinion leaders and upvotes in social media until they are mostly usable.
It’s “I’m making a Python interpreter in rust,” claims emitted into the void with increasing engagement as it grows in usefulness.
Edit: and you can even see that in the HN search above. Every year it’s had a little more functionality and a little more engagement than the last.
Re: RustPython: A Python Interpreter Written in Rust
#49Are there any benchmarks made public in comparison with the python3 interpreter?
Re: RustPython: A Python Interpreter Written in Rust
#50A Python interpreter has to be written in every language.
Just as Doom runs on about any hardware you can think of.