4 ms·

PyPy isn't unmaintained. We are certainly fixing bugs and are occasionally improving the jit. However, the remaining core devs (me among them) don't have the ca

PyPy isn't unmaintained. We are certainly fixing bugs and are occasionally improving the jit. However, the remaining core devs (me among them) don't have the capacity to keep up with cpython. So for supporting new cpython versions we'll need new people to step up. For 3.12 this has started, we have a new contributor who is pushing this along.

m000 7mo ago
The text merged to the documentation is more concise than the PR title: > not actively developed anymore
- masklinn 7mo ago
  Which is just as wrong.
  - hyperpape 7mo ago
    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 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." On the other hand, if you don't support new minor versions day one, but you eventually support them, that's quite different.
    - crote 7mo ago
      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/ https://scientific-python.org/specs/spec-0000/ [1]: https://www.python.org/downloads/release/python-3120/ https://www.python.org/downloads/release/python-3120/
      - SiempreViernes 7mo ago
        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.
        lmeyerov 7mo ago
        The phenomena you're describing is why Cobol programmers still exist, and simultaneously, why it's increasingly irrelevant to most programmers The killer feature is ecosystem: Easily and reliably reusing other libraries and tools that work out-of-the-box with other Python code written in the last few years . There are individually neato features motivating the efforts involved in upgrading a widely-used language & engine as well, but that kind of thinking misses the forest for the trees unfortunately. It's a bit surprising to me, in the age of AI coding, for this to be a problem. Most features seem friendly to bootstrapping with automation (ex: f-strings that support ' not just "), and it's interesting if any don't fall in that camp. The main discussion seems to still be framed by the 2024 comments, before Claude Code etc became widespread: https://github.com/orgs/pypy/discussions/5145 https://github.com/orgs/pypy/discussions/5145 .
        cozzyd 7mo ago
        The alternative is when you run a script that you last used a few years ago and now need it again for some reason (very common in research) and you might end up spending way too much time making it work with your now upgraded stack. Sure you can were you should have pinned dependencies but that's a lot of overhead for a random script...
        SiempreViernes 7mo ago
        Most programmers aren't writing scientific software, which you can tell by claims that nicer f-strings is a pressing concern.
        7mo ago
    - masklinn 7mo ago
      > 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.
HaskLwp 7mo ago
CPython has turned into a commercial enterprise where a small number of developers chase away everyone and periodically get useless projects funded by corporations that go nowhere after five years. Intelligent people have all left. The 150th rewrite of unicodeobject.c is relatively benign (except that it probably costs RedHat money) but the other things are impossible to keep up with.

m000 7mo ago

The text merged to the documentation is more concise than the PR title: > not actively developed anymore

masklinn 7mo ago
Which is just as wrong.
- hyperpape 7mo ago
  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 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." On the other hand, if you don't support new minor versions day one, but you eventually support them, that's quite different.
  - crote 7mo ago
    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/ https://scientific-python.org/specs/spec-0000/ [1]: https://www.python.org/downloads/release/python-3120/ https://www.python.org/downloads/release/python-3120/
    - SiempreViernes 7mo ago
      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.
      - lmeyerov 7mo ago
        The phenomena you're describing is why Cobol programmers still exist, and simultaneously, why it's increasingly irrelevant to most programmers The killer feature is ecosystem: Easily and reliably reusing other libraries and tools that work out-of-the-box with other Python code written in the last few years . There are individually neato features motivating the efforts involved in upgrading a widely-used language & engine as well, but that kind of thinking misses the forest for the trees unfortunately. It's a bit surprising to me, in the age of AI coding, for this to be a problem. Most features seem friendly to bootstrapping with automation (ex: f-strings that support ' not just "), and it's interesting if any don't fall in that camp. The main discussion seems to still be framed by the 2024 comments, before Claude Code etc became widespread: https://github.com/orgs/pypy/discussions/5145 https://github.com/orgs/pypy/discussions/5145 .
        cozzyd 7mo ago
        The alternative is when you run a script that you last used a few years ago and now need it again for some reason (very common in research) and you might end up spending way too much time making it work with your now upgraded stack. Sure you can were you should have pinned dependencies but that's a lot of overhead for a random script...
        SiempreViernes 7mo ago
        Most programmers aren't writing scientific software, which you can tell by claims that nicer f-strings is a pressing concern.
        7mo ago
  - masklinn 7mo ago
    > 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.

HaskLwp 7mo ago

CPython has turned into a commercial enterprise where a small number of developers chase away everyone and periodically get useless projects funded by corporations that go nowhere after five years. Intelligent people have all left. The 150th rewrite of unicodeobject.c is relatively benign (except that it probably costs RedHat money) but the other things are impossible to keep up with.