PyPy is one of the most underrated python implementation. It just makes your pure python code 20x faster without needing to change anything ( if you don't have c++. Extension depends)
We had used PyPy in production , especially on Real-time/ asynchronous web apis that doesn't need machine learning stack
When I wrote asset processing script for a video game in Python, the initial run time was 14 minutes, I was not happy with it because it made the CI times long as hell, so my next step was to rewrite it in C++ and try to sprinkle it with some SIMD magic to speed it up, but out of curiosity, I ran it through PyPy - that brought down the run time from 14 minutes to just 18 seconds (!), needless to say, I was happy enough with the result that I figured these 18 seconds are good enough to not make me waste my time with rewriting the entire tool.
If Python community and CPython developers were more open to PyPy, many things could be changed. A group of people talks about how good having a third-party interpreter in Python community while the whole Python eco-system is heavily relying on the old (maybe good-enough) Python C API.
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.
Core contributors still contributing regularly.
Problem of PyPy was making decisions that's really bad for exposure - like having non GitHub repo because they love mercurial. I love mercurial too but to contribute to opensource have to use GitHub. Which they finally moved now.
I hope PyPy will become popular again.
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.
I still use Python for scripting simple things and for writing web services. I use fastapi for simple things, but I will use Django for anything that needs a database because it has the best migration tooling that I have used.
I guess I could have stated my bias up front as well: mostly a scientific user/dev here. I did enable pypy wheel builds for a pybind11 project and have things magically work, and I've had 'pypy-days' to see if there was any breaking for me (none so far, so kudos!), but other than that never actually used it/found uses for it.
Not really? It is hideously slow. They say that will get fixed when numpy finishes getting ported to the HPy interface, but for now my stuff runs faster in cpython. I could try using numpypy but they have deprecated it.
Well, PyPy was not really accepted by Guido and the PSF people. When we ask questions about PyPy to PSF people, they give unfavorable answers but some of those shows they didn't try much at all. So I don't know what kind of drama they have.
We used Jython very extensively at a former employer, a high frequency trading firm. Originally it was to be used as a configuration language, to allow traders to easily write scripts that configured trading strategies written in Java. The scripts grew into a monstrous ecosystem of applications and analytics.
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.
Those are bridges to native CPython.
There is also GraalPy (https://github.com/oracle/graalpython),
which is a standalone implementation more similar to Jython.
It seems already quite compatible with Python 3.
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 think it might be in reference to the semi-frequent heists that happen, that have real monetary value behind them. EVE players seem to be a special breed. Some of the stories are pretty incredible.
It’s been quite a few years since I worked on this, but spent some time implementing and administering an enterprise infrastructure auto-discovery tool (trying to remember the name - it was a very expensive product from HP, who acquired it from Mercury I think) that was built in Java and exposed a scripting layer to admins via Jython.
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.
I've used pypy in anger a few times. I haven't needed to do reasonably performant webdev in python for awhile, but there was a time when PyPy and the cffi-based database drivers could not be beat by CPython interpreters for non-trivial code. This still might be the case, but I haven't profiled it at all (recently). This was back in python 2.7 days in the mid 2010s.
I think RustPython gets used in ruff (the linter), or at least I saw they were experimenting with that idea. Which is mainly what its built for - running python code in rust, since its still a fair bit slower than cpython.
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.
I have seen them used extensively, especially pypy & jython by big companies. I have seen ironpython twice, but I rarely venture into windows/.NET land.
Pypy gives you at best a single-digit speedup, and requires carefully going through your dependencies and checking all your codepaths. That's rarely a good value proposition for a business - if you're growing fast enough that performance is an issue, you're going to need a bigger speedup than that pretty soon, and if you're taking the time to go through all your codepaths, it doesn't cost a lot more to make a bigger change like switching languages entirely.
I worked on a project (15+ years ago) that used Jython to put a web front end on GDS systems (airline reservation mainframes). It was in production and being used in some of the largest travel call centers at the time. The whole thing was built in Jython.
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 a few solid weekends trying to get it up and running again.
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.
> I will say that the most issues I’ve encountered with Python happened on macOS machines.
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.
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.
I honestly don’t think I’ve ever been able to git clone any python project (that isn’t hello world equivalent), follow the readme and have it just run first shot.
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.
Then work on that repo? Everything after "venv" is too new for me, and I've ignored it and somehow not had any issues. If there are some packages that rely on C code and don't have wheels or whatever, you need to deal with the C ecosystem which is the real hell in my opinion.
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.
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.
Curious what trouble you've had? The Python package ecosystem has always "just worked" for me. That's true regardless of the interpreter implementation I use. I generally test my projects against both CPython and Pypy.
