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

161–170 of 181 posts

Re: Warn about PyPy being unmaintained

#161

Post by latexr »

esafak wrote: post #147
latexr wrote: post #106

Earlier quoted context omitted.

> 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 an…

> Like what? I never saw anything to suggest that is the case. You get blocked if you comment too fast.

That wouldn’t prevent back and forth arguments, the block isn’t fast enough.

Re: Warn about PyPy being unmaintained

#162

Post by glkindlmann »

mattip wrote: post #126
glkindlmann wrote: post #116

Earlier quoted context omitted.

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)

CFFI is fast on PyPy. The JIT still cannot peer into the compiled C/C++ code, but it can generate efficient interface code since there is a dedicated _cffi_backend module built into PyPy. Originally that was the motivation for the PyPy developers to create CFFI.

Thank you for the background info, and sorry for me explaining CFFI (I just wanted to be sure we were talking about the same thing). Being ignorant about PyPy, I honestly had no idea until now that there was a personnel or purpose overlap between CFFI and PyPy. I am very grateful for CFFI (though I only use it API mode).

Re: Warn about PyPy being unmaintained

#163

Post by cozzyd »

ratijas wrote: post #57
Hamuko wrote: post #35

Earlier quoted context omitted.

I'd say they're less of "programs" as they are "six-month trials". What's the plan after six months? And for what's it worth, PyPy isn't even eligible for the Claude trial because they have a meager 1700 stars on GitHub.

If number of stars may help projects adopt AI, that makes me reconsider starring projects at all.

Better to pick projects not hosted on GitHub at all!

Re: Warn about PyPy being unmaintained

#164

Post by ajb »

SiempreViernes wrote: post #119
crote wrote: post #101

Earlier quoted context omitted.

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.

Unfortunately python does add features in a drip-drip kind of way that makes being behind an experience with a lot of niggles. This is particularly the case for the type annotation system, which is retrofit to a language that obviously didn't have one originally. So it's being added slowly in a very conservative way, and there are a lot of limitations and pain points that are gradually being improved (or at least progressed on). The upcoming lazy module loading will also immediately become a sticking point.

Re: Warn about PyPy being unmaintained

#165

Post by bob_theslob646 »

IanCal wrote: post #86
stuaxo wrote: post #84

Earlier quoted context omitted.

The website should have a prominent Donate section, maybe have some tiers of donation like the Ladybird browser does. I wanted to put a little £ towards the project but couldn't see a place to do it.

I don’t disagree about prominence but to share the links under the about section for people here https://pypy.org/howtohelp.html https://opencollective.com/pypy

Thanks for sharing this. I just donated. Been using them for many many years.

Re: Warn about PyPy being unmaintained

#166

Post by jcattle »

apelapan wrote: post #137
crote wrote: post #101

Earlier quoted context omitted.

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…

What's the point of a three year window? It seems like a weird middle-point. Either you are in a position to choose/install your own interpreter and libraries or you are not. If you can choose your own versions and care at all about new releases, you can track latest and greatest with at the very most a few months of lag. Six months of "support" is luxurious in this scenario. If you can't choose your own versions, yo…

I guess the point of a three year window is to be able as an ecosystem to at some point adopt new language features.

When you have some kind of ecosystem rule for that, you can make these upgrade decisions with a lot more confidence.

For example in my project I have a dependency on zstandard. In 3.14 zstandard was added to the standard library. With this ecosystem wide 3 year support cycle I can in good confidence drop the dependency in three years and use the standard lib from then on.

I feel like it just prevents the ecosystem from going stale because some important core library is still supporting a really old version, thus preventing other smaller libraries from using new language features as well, to not exclude a large user base still on an old version.

Re: Warn about PyPy being unmaintained

#167

Post by SiempreViernes »

lmeyerov wrote: post #138
SiempreViernes wrote: post #119

Earlier quoted context omitted.

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.

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 & en…

Most programmers aren't writing scientific software, which you can tell by claims that nicer f-strings is a pressing concern.

Re: Warn about PyPy being unmaintained

#168

Post by saghm »

OJFord wrote: post #91
saghm wrote: post #30

Earlier quoted context omitted.

I'm not sure "major versions" is the most correct term here, but I think your point is spot on

They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case. Or at runtime, you can import things from the standard library which require a minimum 3.x. - .x releases frequently if not always add things, or even change an exis…

> They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.

Are you saying that you'd get an error using the new feature on an old version, or that code that used to parse on old versions would not longer work on the newer version? The former is pretty much a textbook example of a minor version update in "traditional" semver; a single new API function is enough to potentially make new code not work on old versions, since any calls to that function will not work on versions predating it. The latter is what would constitute a "breaking change" in semver; old code that used to work can't be made to no longer work without a major version bump.

I say "traditional" semver because in practice it seems like there are fairly few cases in which people actually seem to fully agree on what semver means. I've always found the "official" definition[1] to be extremely clear, but from what I can tell most people don't really adhere to it and have their own personal ideas about what it means. I've proposed things in projects that are fully within both the letter and spirit of semver quite a few times over the years only for people to object on the basis that it "isn't semver" because they hadn't fully read through the description before. Typically I'll mention that what I'm suggesting is something that semver allows and bring up the page and show them the clause that specifically allows what I'm saying but clarify that I recognize we still might not want to do it for other reasons, and the other person will end up preferring to stick with their initial instinct independent of what semver actually says. This is totally fine, as semver is just one of many versioning scheme and not some universal optimum, but my point is that it's probably more confusing for people to use the same term to describe fairly inconsistent things.

[1]: https://semver.org/

Re: Warn about PyPy being unmaintained

#169

Post by saghm »

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…

> That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.

That's ultimately the point I was trying to make; my inner pedant can't help but feel the need to push back on people using versioning terminology inconsistently, but in practice I don't think it really made much of a difference in this case.

Re: Warn about PyPy being unmaintained

#170

Post by aftbit »

ajross wrote: post #140
cfbolztereick wrote: post #134

Earlier quoted context omitted.

Timely management of external resources is what the `with` statement has been for since 2006, added in python 2.5 or so. To debug these problems Python has Resource Warnings. Additionally, CPython's gc is also only eager in a best effort kind of way. If cycles are involved it can take long to release memory. This will become even more the case in future versions of CPython, in the free threading variants.

Sorry, the with statement is non-responsive. The question isn't whether you "can" write PyPy-friendly code. Obviously you can. The question isn't even whether or not you "should" write PyPy-friendly code, it's whether YOU DID , or your predecessors did. And the answer is "No, they didn't". I mean, duh, as it were. PyPy isn't compatible. In this way and a thousand tiny others. It's not really "Python" in a measurable…

Strongly disagree. If you're relying on Python garbage collection to free file descriptors in a loop, you have a subtle bug that will rear its head in unexpected and painful ways (and by some unwritten law of software, most notably either at 3 AM or when you have an important demo scheduled). This is true whether you're running in CPython or PyPy. It's not hard to avoid - use `with` or `try...finally`. It's not some newfangled language feature. It's not a surprise - you can't write good RAAI code in Python. It's a sign of someone with a poor grasp of the language they're using. If you find things like this, you should fix them, even if you never intend to use PyPy.
Post reply on HN