Hacker Newsnew | past | comments | ask | show | jobs | submit | electroglyph's commentslogin

working on a text game engine similar to Evennia: https://github.com/electroglyph/atheriz

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

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

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.


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.

> 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

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?


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.


> 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.


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

the default heretic with only 100 samples isn't very good, you really need your own, larger dataset to do a proper abliteration. the best abliteration roughly matches a very careful decensor SFT

my wishlist for pyrefly: when using decorated functions, show the underlying type hints instead of the decorators


Cheers Daniel and Mike and team, keep up the good work!


Thank you!


because all the shit is locked down and the corpos can use state violence to stop you from doing so if you manage to succeed


i would read that write-up!


damn this is old. how relevant is this today?


From my reading, almost all of it.


All of it.


that response is not comforting


comes to comments before reading story

reads something from the comments instead

never reads original article submission

leaves satisfied


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: