64 ms·

much respect to the PyPy contributors, but it seems like a pretty fair assessment

swiftcoder 7mo ago
9 months since the last major release definitely feels like a short time in which to declare time-of-death on an open source project
- tempay 7mo ago
  It’s been a lot longer than that. There was a reasonable sized effort to provide binaries via conda-forge but the users never came. That said, the PyPy devs were always a pleasure to work with.
  - masklinn 7mo ago
    > It’s been a lot longer than that. pypy 7.3.20, officially supporting python 3.11, was released in july 2025: https://pypy.org/posts/2025/07/pypy-v7320-release.html https://pypy.org/posts/2025/07/pypy-v7320-release.html We're in March 2026. That's 9 months, which is exactly what GP stated. > There was a reasonable sized effort to provide binaries via conda-forge but the users never came. How is that in any way relevant to the maintenance status of pypy?
- hobofan 7mo ago
  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.
  - masklinn 7mo ago
    > 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.
    - crote 7mo ago
      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.
      - masklinn 7mo ago
        > 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.
      - swiftcoder 7mo ago
        3.11 still has 2 years of active security patches, and has most of the modern python ecosystem on tap. That is a whole different ballgame than stuff stuck in the pre-split 2.x world
- LtWorf 7mo ago
  But if you set up dependabot and automerge some crap every couple of days your project will be very active! Meanwhile my projects got marked as abandoned because those scanners are unaware of codeberg being a thing.

9 months since the last major release definitely feels like a short time in which to declare time-of-death on an open source project

tempay 7mo ago
It’s been a lot longer than that. There was a reasonable sized effort to provide binaries via conda-forge but the users never came. That said, the PyPy devs were always a pleasure to work with.
- masklinn 7mo ago
  > It’s been a lot longer than that. pypy 7.3.20, officially supporting python 3.11, was released in july 2025: https://pypy.org/posts/2025/07/pypy-v7320-release.html https://pypy.org/posts/2025/07/pypy-v7320-release.html We're in March 2026. That's 9 months, which is exactly what GP stated. > There was a reasonable sized effort to provide binaries via conda-forge but the users never came. How is that in any way relevant to the maintenance status of pypy?
hobofan 7mo ago
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.
- masklinn 7mo ago
  > 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.
  - crote 7mo ago
    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.
    - masklinn 7mo ago
      > 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.
    - swiftcoder 7mo ago
      3.11 still has 2 years of active security patches, and has most of the modern python ecosystem on tap. That is a whole different ballgame than stuff stuck in the pre-split 2.x world
LtWorf 7mo ago
But if you set up dependabot and automerge some crap every couple of days your project will be very active! Meanwhile my projects got marked as abandoned because those scanners are unaware of codeberg being a thing.