I discourage everyone from interacting with the python community

Posted Dec 25, 2024 11:41 UTC (Wed) by LtWorf (subscriber, #124958)
Parent article: Tim Peters returns to the Python community

I've had the displeasure of interacting with the python community on different occasions.

When I pointed out that PEP 563 was going to break my library (typedload), Guido's reply just included a workaround (that didn't work) and the matter was closed there.

When, later on, the authors of pydantic raised the same issue (the change breaks all runtime typecheckers), the change was stopped, since it was going to make fastapi broken.

This tells us that there's a silent threshold of how many downloads per day from pypi under which breaking your project is 100% acceptable.

I am currently banned from the python's discuss because I complained about the constant flow of breaking changes that require constant changes to change nothing.

A user advised me to just stop doing updates.

I replied that it was not an acceptable solution since it's how systems get compromised and my replies started to get removed, while people could still give this kind of counterproductive "advice" to me.

I wrote to complain about the moderation that was letting people reply to me but preventing me from pointing out how the advice didn't work.

That got me a silent ban. I got banned without even an email. I only noticed because I opened the website (which I don't open often at all).

I think at this moment the only people who have an interest in taking part are doing so because they are paid by someone to do so. There is no "community" in the regular sense of the word, it's just business interactions between consultants.

I discourage everyone from interacting with the python community

Posted Dec 28, 2024 0:07 UTC (Sat) by dvdeug (guest, #10998) [Link] (4 responses)

> This tells us that there's a silent threshold of how many downloads per day from pypi under which breaking your project is 100% acceptable.

Or rather that there's some metric of how many projects and how important the projects are versus how valuable and important the breaks are. I don't understand what you expect otherwise. As https://xkcd.com/1172/ points out, any change breaks something. (e.g. Any function added to a global namespace, or a local namespace that can be imported, can conflict with existing code.) Unless you freeze the code, like TeX, you have to deal with that. You worry more about breaking important things and worry less about breaking marginal things.

I discourage everyone from interacting with the python community

Posted Dec 29, 2024 20:12 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

In this particular case, the Python community has already acknowledged its mistake in PEP 649[1], and made plans to fix it (in that same PEP and PEP 749), so I'm not sure there's much to accomplish by continuing to discuss it at this point.

[1]: https://peps.python.org/pep-0649/#mistaken-rejection-of-t...

I discourage everyone from interacting with the python community

Posted Dec 29, 2024 22:34 UTC (Sun) by LtWorf (subscriber, #124958) [Link]

I think it's important to potential authors of python libraries to be aware that if your users are aware of caching and do not re-download the same file thousands of times every day, your bugreports about breaking changes will be ignored.

I discourage everyone from interacting with the python community

Posted Dec 29, 2024 22:51 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (1 responses)

As demonstrated by the fact that PEP 649, it was actually possible to not break compatibility!

I expect not breaking compatibility for the lolz to be the default course of actions, even if there would be only tens of projects that get broken instead of hundreds of thousands.

I discourage everyone from interacting with the python community

Posted Jan 10, 2025 17:53 UTC (Fri) by Vorpal (guest, #136011) [Link]

This is how the Rust project is handling it (or at least striving to handle it): doing test builds on all published open source Rust software using a system called "crater".

Sometimes they do accept breakage (you need to be able to fix security and safety issues after all). Often they submit bug reports and even patches to affected projects (if the project is still alive, not much point if it is unmaintained).

And of course, sometimes it still goes wrong (see the issue with the "time" crate early last year). But at least they are trying.

It doesn't feel like Python is making an effort to avoid breakage. They have nothing like Rust's crater (they absolutely could have it, based on packages on PyPI).