What to use instead of nntplib?

aapost aapost at idontexist.club
Tue May 30 16:44:59 EDT 2023


On 5/22/23 12:10, Grant Edwards wrote:
> On 2023-05-21, Retrograde <fungus at 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.



More information about the Python-list mailing list