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
No?
Python may dominate those fields vs other languages, but those fields don't dominate Python use, in my experience.
Whenever I meet a C API issue on RustPython project (yes, I contribute to RustPython), I think about PyPy, and check what's going on C API, and realize 15 years was not enough to change things. Now the momentum of PyPy is not that strong as before. I believe Python community lost a huge chance.
Hope HPy or something can save PyPy. Maybe RustPython also will get a chance around there.
So much time lost by not embracing PyPy.
- https://www.pcgamer.com/inside-the-biggest-heist-in-eve-onli...
- https://www.mmorpg.com/news/an-eve-online-player-has-pulled-...
- https://www.escapistmagazine.com/the-infamous-eve-online-ban...
I'm guessing almost nobody uses it for their SaaS, but outside of that, these runtimes do see some use.
I’m always having to dive in and figure out which packages are missing, wrong version, etc.
As I do this I find myself wondering if the repo maintainers make a habit of actually trying to set up their project from scratch just by following their readmes.
I’m assuming they just get out of date and then leave it to the community to troubleshoot their own installs.
For whatever reason I don’t seem to have nearly the same difficulties trying to clone and run rust or node projects for example.
More generally, the fact that there are about 20 different ways to manage your venvs, and that you seemingly tend to accrete every version of python released in the last 20 years with no clear way of managing all those installations, makes it quite confusing for newbies.
git clone ...
python -m venv venv
source ./venv/bin/activate
pip install -r requirements.txt
All the autotools/cmake/scons, library paths, header paths, PKG_CONFIG, etc. I've had so many issues building C projects that I can't even begin to remember all the issues.
> ...
> pip install -r requirements.txt
No. Usually that will pick up newer versions of the project's transitive dependencies, which will have breaking changes (because these days breaking changes in minor versions is what all the cool kids are doing). Since it's Python you won't find out until you hit the wrong codepath while using the program and get a runtime error.
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.
Same here. It's probably somewhat to do with my only partial MacOS/Homebrew knowledge, but every time I'd ressurect a Python project on MacOS, Homebrew would end up screwing up / confusing / munging the system Python and it's own ones.
Never ran into problems like that on Linux (except for that one time I tried Linux homebrew). Just something about the way homebrew does stuff seems incompatible with me understanding it. Seems to be a "just me" thing though.
Otherwise, for normal job running, cloud infrastructure makes this pretty tricky unless you're a big company. I work for a small company and we run python code on things like azure functions, until they support other python interpreters, we'd need a massive expected benefit to justify that sort of self-building of architecture.
Jython stuck on Python 2 and doesn't have great interop with the rest of the world Python ecosystem, so I wouldn't recommend it for a new project, but it was a big force multiplier in that use case.
I have tested the latest version graalpy-community-23.1.2 as a regular Python interpreter from the command line (i.e., not through a Java program). It was able to run my standard library-only Python scripts, as well as a script that made async HTTP requests with the external library HTTPX. It couldn't run a TUI program that used the Python Prompt Toolkit (`AttributeError: module 'signal' has no attribute 'siginterrupt'`).
I am curious about your experience if you have used GraalPy more than I have.
I just now learned about this project, thanks for pointing it out. I'll be curious how they go about shared data, especially shared str/String.
also I personally happen to depend on Windows support, I'll go popcorn on the future of this project...
I haven’t seen much Jython since, but encountered a few enterprise tools doing this. It was an effective way of enabling advanced use cases and extensions of the existing Java stack without requiring the admin/developer to touch Java.
We switched to pypy several years back and that allowed us to push a great deal more batch jobs through per window with zero code changes.
To be fair, F# filled most of its niche after it "died" so it's not a need in any way, just a wish for nice things because there were a few years where IronPython was a very nice thing to have.