On 5/22/23 12:10, Grant Edwards wrote:
On 2023-05-21, Retrograde <fun...@amongus.com> wrote:
Who ever came up with "Removing dead batteries" as a slogan, when
some of those batteries still work perfectly well, needs to rethink
it. Go ahead and remove code that no longer works, OK. But removing
unpopular modules? That undercuts the entire philosophy of the
platform, in my opinion.
And one of the metrics of "popularity" seems to be "activity"
(e.g. changes committed). For things that have been around for 20+
years and have all the features they need and all of the bugs fixed
(and are now very stable) that lack of "activity" is interpreted as
"unpopular" regardless of how many people are using the module.
--
Grant
To add an additional bitching, I don't really ever see anyone discussing
the dynamics and downsides of github (and things like it). Or how things
like mozilla killing off usenet and mailing lists changes the entire
dynamic of who manages and gets a say in how technology gets to move
forward.
As someone who sees software independence and using free software as
moral imperatives, signing up for github and agreeing to yet another
terms of service is a no go for me, so moving to these platforms locks
me out from contributing. (and a lot of python packages have code that
also works with proprietary operating systems, so non-gnu/gnu hosting
isn't a solution either)
And as someone who uses usenet to post to this list (I object to the
google captcha on the mailing list sign up, and captchas in general), I
imagine eventually a discussion will take place in a place like github
that will do away with this avenue as well.
As far as modern commit dynamics,
Even if I did partake in the modern github style of code distribution,
how many packages have issues where the "maintainers" inherited the
package and really haven't dug deep enough in to the code to see how it
really works. They have issues that sit around for YEARS, and when
someone says "this sucks, this is broken and could be better", and the
githubian response is typically a dismissive "Nothing is stopping you
from making a PR".
Then when you get down to dedicating a month to polishing a PR to extend
or redesign something with the features you need, it just sits there,
for YEARS, because again, the authority that went in to the package in
the first place is often gone, and there is no one with that knowledge
to give the PR the review it deserves.
You end up with your fork, but it is lost, indistinguished from all the
other forks of nothing.
There are now probably dozens of nntplib preservation implementations
floating around, but how do you even consider which one to use? Without
some energy behind it, to be certain in what you are doing, each person
will practically have to download Python3.11 and extract it themselves,
and then either add it in to the latest version themselves, or
comparitively study it vs a collection of new implementations to see
which one feels most like a correct updated standard.
You also have to consider, is this a one off update? At 3.13 will I have
to do it all over again? (at that point, doing it yourself really does
become the only solution).
At the end of the day, what is there boils down to the influence of who
is offering the resources.. And I would say most of that today comes
from the microsofts and googles of the world that have no interest in
preserving the independent ethos of the early web..
I personally am partial to autonomous website distribution, and
mailmanv2 dev collaborations, so you can independently share modified
versions of packages or tutorials you've written for your own purposes,
and if they help others, great.. But I personally haven't found a place
that accepts small cash payments and feels neutral enough to fit my
needs and limited resources.
--
https://mail.python.org/mailman/listinfo/python-list
