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

RustPython

rustpython.github.io

Post reply on HN
Print view View original

161–170 of 244 posts

Re: RustPython

#161

Post by hobofan »

posix_monad wrote: post #137

I'm not convinced that projects like this can really have broad application. The value of Python is interfacing to native libraries, but as soon as you use something like PyPy, you lose access to all of that. It's the same story with the performance orientated forks of cPython.

As some popular libraries begin being authored in Rust (e.g. Polars), I'm wondering whether that could actually be exploited in this approach, by e.g. shipping the "native" libraries as WASM components that can then be called instead of the actual native libraries.

Re: RustPython

#162

Post by pletnes »

galangalalgol wrote: post #69
raverbashing wrote: post #63

Earlier quoted context omitted.

Absolutely It is really underrated. Maybe it's the extension issue, maybe it's something else or maybe it's the fact that it was born as an experimental platform more than anything But it should have been more popular

Python's use base is now dominated by ML and scientific in general isn't it? Both of those communities are relying on extensions completely. I am quite possibly biased as I haven't written any python that didn't use at least numpy.

Pypy supports numpy just fine.

Re: RustPython

#163

Post by antonjs »

jsheard wrote: post #108
DanielHB wrote: post #105

Earlier quoted context omitted.

I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Large python codebases could take like a minute to start if loaded that way. Once it does start then your arguments can make sense, but even so it would still make it impractical for most things. Trust me, when the Javascript dev tells you something will be slo…

> I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Indeed, the web demo takes about 5 seconds to cold-start on my beefy PC, between downloading the 22MB WASM blob and compiling it. It also grows the WASM heap to 160MB after running the simple Fibonacci example, and WASM heaps can't (yet) be shrunk, so the onl…

Depends a little on if you're going to a website to use an app, or running something on a always on PC on say a production floor where the app never gets exited, I'd think.

Re: RustPython

#164

Post by Spivak »

_gabe_ wrote: post #112
esrauch wrote: post #97

Earlier quoted context omitted.

The reality is that the "dark" majority of preexisting code has essentially no performance requirements/concerns; they're business scripts that could literally run on a toaster with no problem if you could get the code onto it. So really most business logic can easily be satisfied by "compile the interpreter to wasm and then run the dynamic language on that", and doing it this way can move existing "learned the hard…

> can move existing "learned the hard way special cases" byzantine business code to something that can run on a web server and be accessed by the companies employees rather than passing around scripts for them to run Or… you could just use Django. The framework built for running python on a web server.

That's totally different, at least out of the box. The use-case seems to be running user-generated scripts that aren't known in advance and can be added/edited/ran in a self-service manner.

The usual way to do this is get a Python interpreter, sandbox the hell out of it on your server, and then run the untrusted code but this obviates the need for security paranoia quite a bit since it's running in the user's environment.

Re: RustPython

#165

Post by pletnes »

ptx wrote: post #125
mavamaarten wrote: post #36

Earlier quoted context omitted.

From a non-python dev perspective: I always struggle with dependencies and versions. I have a script in front of me that I want to run, and am often just frustratingly brute-forcing commands to make it work. Do I: python? python3? pip install? pip3 install? python pip install? python pip3 install? python3 pip install? python3 pip3 install? And then everyone mentions "oh just use venv" or "conda" or docker or... It ju…

Part of the problem is that this used to require third-party tools, which gave rise to lots of different tools, but nowadays everything you need is included in Python itself. The simplest way (in the sense of having the fewest components required) is this, using only built-in tools: $ python3 -m venv --upgrade-deps my-virtual-environment $ my-virtual-environment/bin/pip install whatever-third-party-package $ my-virtu…

This is a fairly good answer but on windows, there’s no python3, so that’s your first command being broken.

Re: RustPython

#166

Post by UncleEntity »

repelsteeltje wrote: post #9
blurbleblurble wrote: post #2

Pretty cool, especially the potential for using python as a scripting language embedded in rust programs. That said, python makes me wince.

Working on a significant C++ code base (shipped as deb, rpm and windows binaries) and wanting to allow some means to customize busyness logic we decided to integrate Python hooks, a couple of years ago. In hindsight, I'd call that decision a mixed blessing. The code level integration (pybind11) was nice and easy, the issues came later. We found operational problems (multithreading), performance (in particular initial…

As a counterpoint, Blender uses python for non-trivial tasks quite successfully. Though...it is quite easy to get blender to crash because python references to C objects become invalidated or whatever.

I've spent tons of time tracking down python crashes from C extensions -- not how a company wants their devs spending their time -- and 99% of the time its just getting the reference counts right so C and python are on the same page. Dependency management of C pointers gets tricky sometimes...

My usual workflow when I'm wrapping a C/C++ library (which I do for 'fun' quite often) is to generate a skeleton of the python module with pybindgen and then hand-tune it until it works. I could write a bunch of custom wrapper code (which I do use when it makes things easier but it gets thrown away after the skeleton is generated so doesn't have to be very robust) and just use the output from pybindgen but that takes a lot more work unless the library falls into pybindgen's happy path. Plus, as I'm doing it for fun, I don't mind spending time to prettify the generated code and add some py-sugar. And the way pybindgen generates docstrings isn't the best so those would have to get handwritten either way.

Admittedly, I just do this kind of stuff as a hobby and industry has different goals so "pinch of salt" and all that.

Re: RustPython

#167

Post by jsheard »

antonjs wrote: post #163
jsheard wrote: post #108

Earlier quoted context omitted.

> I don't think you grasp quite the implications of what I was saying, this kind of approach could take _seconds_ to even start running your python application. Indeed, the web demo takes about 5 seconds to cold-start on my beefy PC, between downloading the 22MB WASM blob and compiling it. It also grows the WASM heap to 160MB after running the simple Fibonacci example, and WASM heaps can't (yet) be shrunk, so the onl…

Depends a little on if you're going to a website to use an app, or running something on a always on PC on say a production floor where the app never gets exited, I'd think.

If you're not targeting the web, what would be the point of running a Python runtime on top of a WASM runtime?

You could just run RustPython as a native binary, or use ol' reliable CPython.

Re: RustPython

#168

Post by philote »

haswell wrote: post #140
fnordlord wrote: post #95

Earlier quoted context omitted.

If you don't mind me chiming in, mostly looking for advice if you've got any. I tend to run into a lot of issues when trying to play with projects that use TensorFlow. I have an Apple Silicon laptop and I seem to always get stuck resolving circular, conflicting dependencies. The worst offender is https://github.com/magenta/magenta . It's such a cool project and I got it running once a few years ago but recently lost…

I will say that the most issues I’ve encountered with Python happened on macOS machines. The default installation was always old, and success using a modern version depended highly on the techniques used to install it. For anything that involves dependencies, I rely on venv or pyenv to create a clean environment. When on macOS, I tended to use docker/containers as well, but primarily because 99% of my Python work has…

I just want to add that using the tool "asdf" for managing python versions on your Mac is very handy. And "direnv" is also great for auto-loading your environment when going into a project directory.

Re: RustPython

#169

Post by ptx »

pletnes wrote: post #165
ptx wrote: post #125

Earlier quoted context omitted.

Part of the problem is that this used to require third-party tools, which gave rise to lots of different tools, but nowadays everything you need is included in Python itself. The simplest way (in the sense of having the fewest components required) is this, using only built-in tools: $ python3 -m venv --upgrade-deps my-virtual-environment $ my-virtual-environment/bin/pip install whatever-third-party-package $ my-virtu…

This is a fairly good answer but on windows, there’s no python3, so that’s your first command being broken.

Right, on Windows the recipe needs a few alterations but is essentially the same. This should work:

  > py -3 -m venv --upgrade-deps my-virtual-environment
  > my-virtual-environment\Scripts\pip install whatever-third-party-package
  > my-virtual-environment\Scripts\python my-script.py
This assumes that the Python launcher (py.exe) was installed when installing Python, which it is by default.

Re: RustPython

#170

Post by globular-toast »

posix_monad wrote: post #141
ixaxaar wrote: post #138

Earlier quoted context omitted.

Pretty much. Ecosystem brings most of the value than any programming language.

It's particular acute with Python. The language itself is poor - the value is in the massive ecosystem (particularly around ML). Compare this to say, Rust, where the safety guarantees are useful in their own right. There would be value in Rust even with zero packages, but I couldn't say the same for Python.

> The language itself is poor

The language is a joy and one of the main reasons it became popular. How do you think it got its ecosystem?

Post reply on HN