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

Warn about PyPy being unmaintained

github.com

Post reply on HN
Print view View original

101–110 of 181 posts

Re: Warn about PyPy being unmaintained

#101

Post by crote »

hyperpape wrote: post #93
masklinn wrote: post #92

Earlier quoted context omitted.

Which is just as wrong.

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 before becoming obsolete. At that point it doesn't even matter whether you want to call it "in active development", it is simply too far behind to be relevant.

[0]: https://scientific-python.org/specs/spec-0000/

[1]: https://www.python.org/downloads/release/python-3120/

Re: Warn about PyPy being unmaintained

#102

Post by johndough »

dxdm wrote: post #89
johndough wrote: post #52

Earlier quoted context omitted.

I don't know about that. For me, f-strings were the last great quality-of-life improvement that I wouldn't want to live without, and those landed in Python 3.6. Everything after that has not really made much of a difference to me.

This reads like you think that "major" version bumps should ony happen when things make a big difference to you personally. At least that's where you land when you follow the logic of your statement. I think you may overrate the importance of your particular use case, and misunderstand what GP meant by "major". The gist of what GP meant is that Python does not exactly follow SemVer in their numbering scheme, and they…

Oh, you are right, I forgot that "major version" is a technical term and incorrectly read it as "For Python, 0.1 increases make a big difference". My bad!

Re: Warn about PyPy being unmaintained

#103

Post by Uptrenda »

mattip wrote: post #18

PyPy 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 performance from a web-page using PyPi without having to install or measure anything.

Re: Warn about PyPy being unmaintained

#105

Post by masklinn »

LtWorf wrote: post #68
tpoacher wrote: post #46

Earlier quoted context omitted.

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

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 JVM's JIT did not care at all for java's types.

Which is not to say JITs don't indirectly benefit mind, type annotations tend to encourage monomorphic code, which JITs do like a lot. But unlike most AOT compilers it's not like they mind that annotations are polymorphic as long as the runtime is monomorphic...

Re: Warn about PyPy being unmaintained

#106

Post by latexr »

pbhjpbhj wrote: post #88
latexr wrote: post #76

Earlier quoted context omitted.

> unfortunately, @-pinging does not work on this site I’d call it fortunate, and a feature. Not pinging certainly avoids many discussions becoming too heated too fast between two people and lets other opinions intervene.

There are systems in place to prevent fast back-and-forth arguments. Not having a mentions functionality for those who wish to use it doesn't seem to to change anything around over-heated discussions. I'd make @ a page like 'threads' which just includes any comments with @$username.

> There are systems in place to prevent fast back-and-forth arguments.

Like what? I never saw anything to suggest that is the case.

> Not having a mentions functionality for those who wish to use it doesn't seem to to change anything around over-heated discussions.

Of course it does. If you have to keep checking manually, eventually you’ll get distracted. By the time you come back, if you do, there may already be another reply to the reply and you may no longer feel the need to comment. Nor will you be inclined to respond to a comment made days later in a nested discussion, because you won’t find it. But people just arriving at the thread might, and continue the discussion with new perspectives.

> I'd make @ a page like 'threads' which just includes any comments with @$username.

To each their own, I’m thankful HN doesn’t have that feature.

Re: Warn about PyPy being unmaintained

#107

Post by crote »

masklinn wrote: post #99
hobofan wrote: post #51

Earlier quoted context omitted.

It is also lagging behind in terms of Python releases. They are currently on 3.11, which was released 3.5 years ago for mainline Python.

> It is also lagging behind in terms of Python releases. Which it has always been, especially since Python 3, as anyone who's followed the pypy project in the last decade years is well aware.

The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.

Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

Re: Warn about PyPy being unmaintained

#108

Post by masklinn »

hyperpape wrote: post #93
masklinn wrote: post #92

Earlier quoted context omitted.

Which is just as wrong.

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…

> 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 is literally a Python 3.12 milestone in the bug tracker.

> my response is "ok, then I don't care whether it's under active development, I (and 99.9% of other people) should care about whether it's going to support new minor versions."

It sounds a lot more like your actual response is "I don't care about pypy".

Which is fine, most people don't to start with. You don't have to pretend just to concern-troll the project.

Re: Warn about PyPy being unmaintained

#109

Post by crote »

jorvi wrote: post #41
_zagj wrote: post #19

Odd how you still see announcements of this nature if Anthropic's marketing is be believed.

Yup. For me the biggest signifier is Spotify. They claim their (best) devs don't even code anymore, they use an internal AI tool that they just send prompts to which then checks out a personal test build that they can download off of Slack. "A new feature in 10 minutes!" Okay, if that is the case, why have we only seen like 3-4 minor new QoL improvements in Spotify the last ~12 months, with no new grand features? And…

> why have we only seen like 3-4 minor new QoL improvements

You are seeing improvements? From what I can tell, my user experience has only been going downhill over the past years - even pre-AI...

Re: Warn about PyPy being unmaintained

#110

Post by masklinn »

crote wrote: post #107
masklinn wrote: post #99

Earlier quoted context omitted.

> It is also lagging behind in terms of Python releases. Which it has always been, especially since Python 3, as anyone who's followed the pypy project in the last decade years is well aware.

The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries. Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

> The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.

Which is a concern for those libraries, I've not seen one thread criticising (or even discussing) numpy's decision.

> Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

But it's not, and either way that has nothing to do with uv, it has to do with people who use pypy and the libraries they want to use.

Post reply on HN