How is it about safety then? All the Rust program parts scripted using python are unsafe?
RustPython
131–140 of 244 posts
Re: RustPython
#132How does their garbage collection work? Especially in Rust it would be cool to see a concurrent collector.
Re: RustPython
#133Earlier quoted context omitted.
Why does it make you wince?
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…
Thankfully, most distros/OSs don't ship with Python 2 anymore, so `python` will just link to `python3`.
Re: RustPython
#134> "it can be compiled to WebAssembly in order to run Python in the browser." I have seen this approach with C-python and NodeJS already and I think it simply not viable, what they are suggesting is compiling the runtime (the same one you use in non-wasm projects) to wasm and then run your python code on top of it. This is a double-whammy of performance degradation, you basically have two JIT-compilation steps happeni…
I can't speak for rustpython, but you can partially evaluate dynamic languages in wasm with something like wizer https://github.com/bytecodealliance/wizer. So you can let the runtime do all the parsing and compiling ahead of time. We do this with javascript (quickjs). It does have a few downsides regarding memory size but it is pretty fast.
Re: RustPython
#135Earlier 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…
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…
What do you envision these scripts to be doing that it would matter if it takes minutes, hours even, to start? Fire and forget.
Granted, the environmental cost to all that extra energy consumption may not be palpable. Then again, you're exactly choosing Python in the first place if you care about the environment.
Re: RustPython
#136Earlier quoted context omitted.
Why does it make you wince?
Personally, I wince at Python because, while I view it as a quick-and-dirty scripting language, some people write production code in Python. And here we are ten years later, stuck with code that reads a few metrics from the system, packages them into JSON, and sends them to an API for monitoring. The code takes 7 seconds at 100% CPU to resolve the imports, every time it runs.
You can write bad code in any language, I fail to see how that's Python's problem.
Re: RustPython
#137I'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.
Re: RustPython
#138I'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.
Pretty much. Ecosystem brings most of the value than any programming language.
Re: RustPython
#139How do extensions work with interpreters written other languages? Does the interpreter still expose a C API?
No.
…and this one is no exception -> https://github.com/RustPython/RustPython/issues/1940
Packages that rely on c dependencies like numpy, etc. only work if you write a custom implementation by hand; the “normal” package flat out doesn’t (and cannot) work.
So basically you get no packages that use native extensions, unless the project explicitly implements support for them.
Pypy is the only implementation I’m aware of that has implemented a c api that is mostly compatible (see https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...)
For eg. Python running in a .net host or a Java host… I think this kind of compatibility would just be flat out impossible.
For rust… hm… probably possible. For wasm? Definitely not.
Re: RustPython
#140Earlier quoted context omitted.
Python has been my go-to for prototyping since 2003. Maybe I’ve just adjusted to its quirks, but I keep returning to it despite picking up another dozen languages since. I’ve encountered other people who hate it, but never understood why; what issues are you experiencing?
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 been in a Linux environment and I wanted like-for-like as much as possible. But a good version manager directly on macOS should help quite a bit.