At this point it's probably better investing time and money into RustPython[1][2].
Warn about PyPy being unmaintained
111–120 of 181 posts
Re: Warn about PyPy being unmaintained
#112PyPy core dev here. If anyone is interested in helping out, either financially or with coding, we can be reached various ways. See https://pypy.org/contact.html
Another suggestion to add for you all (IDK how helpful.) When I see PyPy I see that its speed is faster for CPU-bound work but I'm thinking there is also I/O bound work that would see significant increases in the load they can handle. You could host a page that benchmarks common tasks like HTTP req/s (different types) with asyncio vs CPython. Could even have an automated tool that allows projects to benchmark perform…
Benchmarks are tricky. Do you have a specific use case you want sped up?
Re: Warn about PyPy being unmaintained
#113Earlier quoted context omitted.
Also big notice that it is unmaintained
And that the corporations using their work should donate if they actually want it maintained.
Donating is for individuals. If a corporation wants something done, they can hire or contract someone to do that thing.
Re: Warn about PyPy being unmaintained
#114What annoys me is the name. Early morning it took me a moment to realise that PyPy is not PyPi, so at first I thought they referred to PyPi. Really, just for the name confusion alone, one of those two should have to go. Edit: I understand the underlying issue and the PyPy developer's opinion. I don't disagree on that part; I only refer to the name similarity as a problem.
Wikipedia tells me that the package index PyPI (launched in 2003) is about 4 years older than the interpreter PyPy (first released in 2007). Still, at its core, PyPy is a Python interpreter which is itself written in Python and the name PyPy fittingly describes its technical design.
No. PyPy development was ongoing long before the first release. The first intact commit in the PyPy repo is from February 2003: https://github.com/pypy/pypy/commit/6434e25b53aa307288e5cd8c....
And that commit indicates there's been development going on for a while already. The commit message is:
"Move the pypy trunk into its own top level directory so the path names stay constant."
PyPy migrated from Subversion to git at some point. Not sure how much of the history survived the migration.
Re: Warn about PyPy being unmaintained
#115Earlier quoted context omitted.
pypy existed long before type annotations were a thing
And JITs often don't care for type specifications as they can generally get better info from the runtime values, need to support that anyway , and for languages like python the type specifications can be complete lies anyway. They also might support (and substitute) optimised versions of types internally (e.g. pypy has supported list specialisation for a long time). Maybe it's changed since, but last I checked the JV…
PyPy may not care in principle, but RPython does, being a kind of python dialect designed for static compilation that is intended for writing JIT engines like PyPy.
Re: Warn about PyPy being unmaintained
#116PyPy is a fantastic achievement and deserves far more support than it gets. Microsoft’s “Faster CPython” team tried to make Python 5x faster but only achieved ~1.5x in four years - meanwhile PyPy has been running at over 5x faster for decades. On the other hand, I always got the impression that the main goal of PyPy is to be a research project (on meta-tracing, STM etc) rather than a replacement for CPython in produc…
Third party libraries like SciPy scikit-learn, pandas, tensorflow and pytorch have been critical to python’s success. Since CPython is written in C and exposes a nice C API, those libraries can leverage it to quickly move from (slow) python to (fast) C/C++, hitting an optimum between speed of development and speed of runtime. PyPy’s alternative, CFFI, was not attractive enough for the big players to adopt. And HPy, a…
Sorry can you explain more the connection between PyPy and CFFI (which generates compiled extension modules to wrap an existing C library)? I have never used PyPy, but I use CFFI all the time (to wrap C libraries unrelated to Python so that I can use them from Python)
Re: Warn about PyPy being unmaintained
#117If anyone else is also barely aware and confused by the similar names, PyPI is the Python Package Index, which is up and maintained. PyPy is "A fast, compliant alternative implementation of Python." which doesn't have enough devs to release a version for 3.12[0]. [0]: https://github.com/orgs/pypy/discussions/5145
and mypy is "an optional static type checker for Python" [0] Given that both pypy (through RPython) and mypy deal with static type checks in some sense, I kept confusing the two projects until recently. Also, I just learnt (from another comment in this post) about mypyc [1], which seems to complete the circle somehow in my mind. [0] https://www.mypy-lang.org/ [1] https://github.com/mypyc/mypyc
Don't forget about dmypy, the daemon version of mypy.
Re: Warn about PyPy being unmaintained
#118PyPy is a fantastic achievement and deserves far more support than it gets. Microsoft’s “Faster CPython” team tried to make Python 5x faster but only achieved ~1.5x in four years - meanwhile PyPy has been running at over 5x faster for decades. On the other hand, I always got the impression that the main goal of PyPy is to be a research project (on meta-tracing, STM etc) rather than a replacement for CPython in produc…
> PyPy is a fantastic achievement and deserves far more support than it gets
PyPy is a toy for getting great numbers in benchmarks and demos, is incompatible in a zillion critical ways, and is basically useless for large-scale development for anything that has to interoperate with "real" Python.
Literally everyone who's ever tried it has the experience that you mock up a trial for your performance code, drop your jaw in amazement, and then run your whole app and it fails. Until there's a serious attempt at real 100% compatibility, none of this is going to change.
Also none of the deltas are well-documented. My personal journey with PyPy hit a wall when I realized that it's GC is lazy instead of greedy. So a loop that relies on the interpreter to free stuff up (e.g. file descriptors needing to be closed) rapidly runs into resource exhaustion in PyPy. This is huge, easy to trip over, extremely hard to audit, and... it's like it's hidden lore or something. No one tells you this, when it needs to be at the top of their front page before your start the port.
Re: Warn about PyPy being unmaintained
#119Earlier quoted context omitted.
I think the most significant boundary is given by the question: "is there a plan to support new minor versions of Python?" It sounds like there is not. There may be non-zero maintenance work happening, but a project that only maintains support for old versions and will never adopt new ones is functionally one that the ecosystem will eventually forget about. Maybe you call that "under active development" but my respon…
More specifically, the Scientific Python community through SPEC 0[0] recommends that support for Python versions is dropped three years after their release. Python 3.12 was released in October 2023[1], so that community is going to drop support for it in October 2026. Considering that PyPy is only just now starting to seriously work on supporting 3.12, there's a pretty high chance that it won't even be ready for use…
This is silly, there's no killer feature for scientific computing being added to python that would make an existing pypy codebase drop that dependency, getting a code validated takes a long time and dropping something like pypy will require re-valditating the entire thing.
Re: Warn about PyPy being unmaintained
#120Earlier quoted context omitted.
Another suggestion to add for you all (IDK how helpful.) When I see PyPy I see that its speed is faster for CPU-bound work but I'm thinking there is also I/O bound work that would see significant increases in the load they can handle. You could host a page that benchmarks common tasks like HTTP req/s (different types) with asyncio vs CPython. Could even have an automated tool that allows projects to benchmark perform…
Benchmarks are tricky. Do you have a specific use case you want sped up?
I have to say the speed comparison on the front page seems hard to read / backwards
I feel like you should either put absolute numbers side by side or how much faster pypy is (instead of how much time it takes)