why is the nntp library deprecated in recent python versions? they
clearly lost touch

On wed, 14 aug 2024 07:07:59 -0700, test wrote:

> why is the nntp library deprecated in recent python versions? they
> clearly lost touch

Agreed! Sadly, they deemed it useless at some point I believe. Plus, of
course, someone has to maintain it. Not sure, however, what that entails
like how much work there is. Are there C libraries involved? No idea.

Save a copy of the source and it'll probably work for quite some time, but
I suppose it will break some time in the future.

I use Usenet for my secondary backup since I don't trust USB drives
anymore. Cheap solution and I get more or less unlimited storage for about
16 years (5900ish days). I can get a cheap account, post what I want, then
I don't have to pay again until the end of those retention days and I
could get an account then and get back my stuff. In the mean time, sure,
Usenet could end so better keep track of the news and check when the
servers are vanishing. Altopia went extinct not too many years ago and
Chris had been running it for 26 years I believe it was.

Those naysayers just don't think farther than to the tip of their nose.
The bubblegum generation has more or less destroyed both Usenet and the
web with their crap.

--
Gilmeh

I'd rather have a free bottle in front of me than a prefrontal lobotomy.
-- Fred Allen [Also attributed to S. Clay Wilson. Ed.]

"test" <abc@test.de> writes:
> why is the nntp library deprecated in recent python versions? they
> clearly lost touch

nntplib is not vanishing into thin air. It's just not going to be part
of a default Python installation. (It's not there in Python 3.13.0rc1.)

In my opinion the use of the word "deprecated" is misleading.

$ python3
Python 3.12.4 (main, Jun 27 2024, 13:53:59) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import nntplib
<stdin>:1: DeprecationWarning: 'nntplib' is deprecated and slated for removal in Python 3.13
>>>
$

<https://pypi.org/project/nntplib/>

The rationale for removing nntplib and other modules from the default
installation is explained in PEP 0594 <https://peps.python.org/pep-0594/>.

"""
Back in the early days of Python, the interpreter came with a large
set of useful modules. This was often referred to as “batteries
included” philosophy and was one of the cornerstones to Python’s success
story. Users didn’t have to figure out how to download and install
separate packages in order to write a simple web server or parse email.

Times have changed. With the introduction of PyPI (née Cheeseshop),
setuptools, and later pip, it became simple and straightforward to
download and install packages. Nowadays Python has a rich and vibrant
ecosystem of third-party packages. It’s pretty much standard to either
install packages from PyPI or use one of the many Python or Linux
distributions.

[...]

The nntplib module implements the client side of the Network News
Transfer Protocol (nntp). News groups used to be a dominant platform for
online discussions. Over the last two decades, news has been slowly but
steadily replaced with mailing lists and web-based discussion
platforms. Twisted is also planning to deprecate NNTP support and pynntp
hasn’t seen any activity since 2014. This is a good indicator that the
public interest in NNTP support is declining.

The nntplib tests have been the cause of additional work in the recent
past. Python only contains the client side of NNTP, so the tests connect
to external news servers. The servers are sometimes unavailable, too
slow, or do not work correctly over IPv6. The situation causes flaky
test runs on buildbots.
"""

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

On 8/14/24 13:14, Keith Thompson via Python-list wrote:

> The rationale for removing nntplib and other modules from the default
> installation is explained in PEP 0594 <https://peps.python.org/pep-0594/>.
>
> """
> The nntplib tests have been the cause of additional work in the recent
> past. Python only contains the client side of NNTP, so the tests connect
> to external news servers. The servers are sometimes unavailable, too
> slow, or do not work correctly over IPv6. The situation causes flaky
> test runs on buildbots.
> """

Sounds like we need somebody to write an NNTP server for the stdlib! :-)

--
~Ethan~

> it became simple and straightforward to
> download and install packages.

I think the right word for this is "delusional". But people get
offended when other people use the right words. Instead they want a
grotesque round-about way of saying the same thing...

So, the grotesque round-about way of saying this, if you are still
reading that is... Even if pip, setuptools and friends worked well
(which they don't) there are big problems that these tools cannot
solve:

* Network partition
* Version mismatch
* Competition between different installer tools
* Increased requirement for vetting and validation
* Shortening shelf life of existing projects

But hey, this is just letting off steam. Nobody cares. The decision
was already made and it won't be unmade. And, in the grand scheme of
things this is a drop in a bucket of the awful decisions that were
guiding Python in the last decade or so.

On 14/08/2024 23:32, Left Right via Python-list wrote:
>> it became simple and straightforward to
>> download and install packages.
>
> I think the right word for this is "delusional".

I agree. But even if it worked it doesn't alter the fact
that by not having batteries included it puts the onus on
developers to build complex installs since their clients
can't be expected to use pip etc. And a vanilla python
no longer comes with the batteries. It greatly adds to
the Python users workload even as it lightens the library
maintainers load.

It was certainly one of the main reasons I adopted python
rather than perl. But thankfully I'm retired now so it's
somebody else's problem.

> But hey, this is just letting off steam. Nobody cares.

Lots of people care but the ability to influence these
decisions seems to have been removed far from the
general python user community. Python has moved from
the BDFL/Bazaar to the Committee/Cathedral. Probably
an inevitable consequence of its current "popularity".

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

On 8/14/24 15:32, Left Right via Python-list wrote:

> I think the right word for this is "delusional". But people get
> offended when other people use the right words. Instead they want a
> grotesque round-about way of saying the same thing...
>
> So, the grotesque round-about way of saying this, if you are still
> reading that is... Even if pip, setuptools and friends worked well
> (which they don't) there are big problems that these tools cannot
> solve:
>
> * Network partition
> * Version mismatch
> * Competition between different installer tools
> * Increased requirement for vetting and validation
> * Shortening shelf life of existing projects
>
> But hey, this is just letting off steam.

No need to hit <Send> if you're just venting.

> Nobody cares.

Yeah, people do.

--
~Ethan~

On 8/14/24 15:56, Alan Gauld via Python-list wrote:

> Lots of people care but the ability to influence these
> decisions seems to have been removed far from the
> general python user community. Python has moved from
> the BDFL/Bazaar to the Committee/Cathedral. Probably
> an inevitable consequence of its current "popularity".

The move came because of the vitriol directed at the BDFL (and others) with every major (and sometimes minor) change to
Python.

Every action has consequences, and in this case the consequence was that we are now run by committee.

--
~Ethan~

On 15/08/24 10:56, Alan Gauld via Python-list wrote:
> On 14/08/2024 23:32, Left Right via Python-list wrote:
> Lots of people care but the ability to influence these
> decisions seems to have been removed far from the
> general python user community. Python has moved from
> the BDFL/Bazaar to the Committee/Cathedral. Probably
> an inevitable consequence of its current "popularity".

Perhaps in the ?good, old, days when Python was the small, scrappy
language a strong community formed because there was a strong sense of
"us" - as in, "us against the world". This atmosphere generates
"cohesion" within the group.

Does it (still) exist today? Where/when?

Python is a victim of its own success. It is now used in so many
different fields within computing it is not possible for one person to
say "I use it all". Thus, when someone says (s)he is a "Python
Programmer" what is meant is most-likely one of web/front-end work,
back-end/server/networking, data science, machine learning, etc.

As a PUG-Leader, this a daunting part of trying to generate and keep
'community'. 'Data science people' won't attend 'web' meetings
(by-and-large), and vice-versa - indeed some even feel the 'right' to
moan that some other area of Python happens to be the topic for the next
meeting.

The converse view (which is seldom well-taken if offered as a riposte to
such complaints) is that if folk volunteer in some way, their efforts
will (most likely) be embraced with gratitude - but how many do make
such offers/participate in a practical fashion!

Whither community? Cohesion?

Thus, a grave difficulty for leaders who are unable to see these sorts
of concerns - and act accordingly. A shift that should have occurred
within steering groups as Python grew in popularity, was to add
applications-expertise to the central group of Core Maintainers.
However, unless there is trust and respect between members, one may be
(too) quick to reject comments and ideas from 'another'.

Perhaps Python's state-of-democracy is heavily influenced by
nation-state politics, where the desire for division seems to be
overwhelming ideas of community/society? How does such benefit community
- those represented?

Growth and size will inevitably require adaption. Almost inevitably it
brings 'structure'. Whereas some do care (per @Alan's point), the
average Python-programmer probably doesn't understand the current
structures, and might even eschew such/reject their need.

How does this fit with "community"? What is personal-responsibility?
What channels should folk be using? Are members of the community feeling
'heard'?

If a committee perceives themselves besieged, the tendency is to look
inwards and become determinedly-defensive - which, in cases like this,
is likely the exact opposite of what the decision's opponents desire!

How should a 'community' handle such? How should decisions be made, and
then communicated in such a way as to promote and build community, even
though some members may be disappointed?

Recently there was an election for PSF members. Did 'everyone' participate?

What decision-making processes are usable in the face of such large
numbers - and how seriously are/would they be taken by 'the average
Python user'?

--
Regards,
=dn

On 8/14/24 19:43, dn via Python-list wrote:

> Recently there was an election for PSF members. Did 'everyone' participate?

Of course not, I didn't simply because I don't know enough have a cogent
opinion. But conversations like this are would seem to be good if they
don't degenerate into name calling. As I look at my nintyieth in a
month or so I always hope next year will be better. Please make it so.

> What decision-making processes are usable in the face of such large
> numbers - and how seriously are/would they be taken by 'the average
> Python user'?
>

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis