Argh, why is Python 3.15 not out yet?

https://docs.python.org/3.15/library/stdtypes.html#frozendict

@xgranade because they have to include more Rust dependencies and slop first?

@mirabilos I'm all in favor of adding Rust into CPython, it's a good idea that's long overdue. But that was pushed back to 3.16 for the initial test.

As for slop, I fear you're at least in part correct — the amount of slop in CPython is very small so far, but it's not zero, and there's no policies in place that I've been able to find to keep it from growing.

@xgranade it’s CPython not RustPython; that step makes it unbuildable on half the platforms supporting it 😾🤬

On slop: I wonder, for things with small amounts of slop, about just taking upstream distfiles and adding individual patches that revert the slop to the packaging. Of course this has the offending, stolen work show up twice, but anything else will also still have it in some form and is less practical. Also, these patches can document the issue, and the possible bugs reintroduced by the reverts. What do you think about it?

@mirabilos I mean, maintaining a fork of Python, even one that's incredibly close in edit distance, also means forking a hell of a lot of infrastructure that is completely infeasible without PSF-level budgets and volunteer staff.

I think a much better approach, and one that's more likely to succeed in the short term, is to appeal to that there's a lot of good folks in the PSF trying to do things better, and O(1) malicious actors trying succeeding at making it worse.

@mirabilos As far as Rust in Python, I'll have to categorically and strongly disagree. Using memory-safe and maintainable system languages is good, actually. C is a bad language and has held back so much software development it's ridiculous.

But that's neither here nor there... just wishing I could use frozendict now, without extra dependencies.

@xgranade I disagree on the languages, but it’s good that there can be plurality.

What isn’t acceptable is for the explicitly-C implementation to suddenly require Rust.

Write a different one under a different name (or fork, if you need to do it incrementally), but keep the one in C supported and working.

@xgranade what I was thinking about is:

If project X has a few known slop commits in version 1.2.3 that aren’t in version 1.2.2, there are a few ways to deal with this:

• not upgrading
• using X-1.2.3.tgz and adding explicit slop-reverting patches to the packaging, to be applied before building (think debian/patches or BSD ports)
• cloning the X git repo, checking out the 1.2.3 tag, reverting the commits, then rolling an 1.2.3-without-slop tgz yourself, then using that in the packaging

For the latter one to be auditable and reproducible, the repo needs to be publicly accessible, so the slop’s somewhere either way.

I’ve got a concrete example in mind already (where (last time I looked) the commit was a new test case only anyway) and which I need to update and where Debian-style packaging is indeed used, and where I already have a debian/patches/revert/ directory with an unhelpful upstream commit (changing behaviour incompatibly in a stable branch).

I was thinking of debian/patches/revert/slop/ files to revert the upstream commits, then debian/patches/fixes-after-reverts.diff to clean up afterwards if these reverts break the build.

But still keep the “AIn’t” badge on my repo. The packages built from it, and the source package with patches applied (without the origtgz and the debian/patches/ tree), are.

Or should I choose the different way and roll my own origtgz from a branch in the packaging repo that tracks upstream but with slop reverted… (keeping debian/patches/revert/ for the semantically-undesirable patch). Downside is more work (also for reviewers), upside is the source package is also slop-free (TTBOMK) and free of files with questionable legal status… so perhaps I ought to indeed do this.

@nik wdyt? I would welcome feedback on this.

@wouter @xgranade yeah, I give it about a decade before it can realistically be used, iff the Rust/Crab community can get off their use of “crates” and into dynamic linking and all that.

Meanwhile, Eurydike looks more promising, but an onus on the software author; Rust/Crab users are majorly like militant vegans and therefore won’t even consider it.

@mirabilos @wouter Cmon, don't come into my mentions to shit on Rust. I get that saying one nice thing about Rust is a guaranteed way to get the C/C++ folks mad, but good grief.

Anyway, whole program analysis is good, actually, and is a technique that C and C++ have prevented for *decades*. We need to put an end to institutionalized gatekeeping and that means getting past C and C++ towards usable languages instead.

@xgranade @wouter let’s just agree to disagree, then? I hadn’t expected this subthread to blow up this much, and I don’t mind stopping it here.