Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 594 – Removing dead batteries from the standard library

peps.python.org

Post reply on HN
Print view View original

71–80 of 95 posts

Re: PEP 594 – Removing dead batteries from the standard library

#71

Post by popularonion »

nrclark wrote: post #16

There are some things on the list that I totally get. We probably don't need support for .aif files in Python's stdlib, or support for the Sun directory service. But I hate to see these get removed: - cgi - pipes - uu - telnetlib A lot of people still use CGI. Yes, it's slow / low-performance / etc. It's also a perfectly fine way to make a knockabout internal service. Pipes is a small pure-Python module, with nothing…

> “Telnetlib is personally useful to me, since telnet is one of the easiest ways to interact with a qemu VM's console.”

The kind of person behind a decision like this has never heard of QEMU and won’t care even if you tell them. “Why don’t you use Docker or k8s?”

Re: PEP 594 – Removing dead batteries from the standard library

#72

Post by qbasic_forever »

mjw1007 wrote: post #65
munch117 wrote: post #41

Earlier quoted context omitted.

If you want to step up and be the maintainer of one or more of these modules in the standard library, I'm pretty sure you would be welcomed. PEP 594 is basically just a formalisation of the fact that no one has volunteered to do this yet.

Looking at https://discuss.python.org/t/pep-594-removing-dead-batteries... someone did volunteer to maintain cgi and cgitb. But nonetheless those modules remained listed in the PEP.

It wasn't a strong enough argument to overcome the final decision that cgi and cgitb are modules which never would be accepted in python today. There were three years to discuss this issue and make a case--was that process not enough?

Re: PEP 594 – Removing dead batteries from the standard library

#73

Post by ptx »

> A lean and mean standard library benefits platforms with limited resources like devices with just a few hundred kilobyte of storage (e.g. BBC Micro:bit).

It probably would, but the standard library is never going to be reduced to that size (I hope!), so how do these removals benefit those devices?

Re: PEP 594 – Removing dead batteries from the standard library

#74

Post by qbasic_forever »

nitrogen wrote: post #67
qbasic_forever wrote: post #58

Earlier quoted context omitted.

Not to mention python has an entirely open proposal process where anyone at any point could have commented and expressed a desire to keep these libraries in the standard library. It seems after this entire process not enough people need them in the standard library.

> It seems after this entire process not enough people need them in the standard library. I'm reminded of the Hitchhiker's Guide to the Galaxy: "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard."

That has no bearing at all on the PEP process and is a gross mischaracterization of it. It's clearly documented and open. If you subscribe to any python development mailing list or even the PEP github repo you would have seen this issue. You would have seen links to the discussion which was open for _three years_ and had over 100 comments on it. This was not a decision that was hidden in any way from the python userbase.

Re: PEP 594 – Removing dead batteries from the standard library

#75

Post by qbasic_forever »

nitrogen wrote: post #68
qbasic_forever wrote: post #59

Earlier quoted context omitted.

Well apparently it's not heavily enough used that any of its current users were motivated enough to discuss the PEP and make a strong case for keeping it in the standard library. The discussion was open for _three years_ and had hundreds of comments: https://discuss.python.org/t/pep-594-removing-dead-batteries... The outcome is that there isn't enough usage to merit this being in the standard library.

I suspect there's very little overlap between users of development software and participants in the bureaucracy that designs the software. The requisite personality types are very different.

If you're developing software that depends on a python standard library it is on you to subscribe to the relevant mailing lists so you can be notified of security issues, deprecations, changes, etc. There is not bureaucracy here to be aware of what's happening, or even comment on the changes.

Re: PEP 594 – Removing dead batteries from the standard library

#77

Post by williamsmj »

nitrogen wrote: post #67
qbasic_forever wrote: post #58

Earlier quoted context omitted.

Not to mention python has an entirely open proposal process where anyone at any point could have commented and expressed a desire to keep these libraries in the standard library. It seems after this entire process not enough people need them in the standard library.

> It seems after this entire process not enough people need them in the standard library. I'm reminded of the Hitchhiker's Guide to the Galaxy: "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard."

If your implication here is that the very public backwards compatibility statement, the mailing lists where PEPs are discussed and approved/rejected, and the website python.org are a "locked filing cabinet", it may interest you to learn that this exact PEP was discussed over two threads and nearly 1000 posts on Hacker News: https://news.ycombinator.com/item?id=19948642, https://news.ycombinator.com/item?id=19985802.

Re: PEP 594 – Removing dead batteries from the standard library

#78

Post by mark-r »

mananaysiempre wrote: post #39
codedokode wrote: post #14

I don't understand the motivation to remove MSI support. The document says: > Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a new deployment model First, MSI has better OS support than AppX, second, many users are still using Windows 7 and won't be able to use AppX. MSI is not some 30-years old deprecated standard.

FWIW, CPython officially follows Microsoft’s support schedule on Windows systems, so versions ≥ 3.9 won’t even install on Windows 7. (Some reasonable people like it and some don’t, but this has been the official stance for a long time.) As for MSI, I’m torn: it is the most widely-supported and reliable packaging approach for Windows and, at the same time, a 20-year-old undocumented dumpster fire of an archive format…

Windows 7 is the best version of Windows Microsoft ever made, and I won't give it up until I have absolutely no choice. I'm already disappointed that I can't get Python 3.9 - I don't understand why they have to actively bar you from installing it rather than just telling you to use it at your own risk.

Re: PEP 594 – Removing dead batteries from the standard library

#79

Post by oblvious-earth »

dnsco wrote: post #45

> Post-History 21-May-2019, 04-Feb-2022 I would express all of the concerns being expressed here were debated ad nauseam over the three year political process of getting this proposal accepted. If you want to vent your fears and frustrations in a hopefully more productive way, you can get involved in Python's process. All that is to say, I'm thankful that the Python community gets things done, and people are willing…

I am happy that people like Brett Cannon are in the Python Core Dev team getting things moving along.

For reference here is the first discussions: https://discuss.python.org/t/pep-594-removing-dead-batteries... and https://mail.python.org/archives/list/python-dev@python.org/...

And nearly 3 years later here is the second discussion: https://discuss.python.org/t/pep-594-take-2-removing-dead-ba...

I thought that feedback from the first discussion was carefully considered and I'm pretty happy with take 2. I have used the some of the modules being removed but largely agree now they are either legacy or there are significantly better third party options.

Re: PEP 594 – Removing dead batteries from the standard library

#80

Post by loeg »

jandrese wrote: post #44
loeg wrote: post #8

Earlier quoted context omitted.

msilib and nis are probably Windows-only.

NIS is definitely not a Windows thing. Maybe the python module would appear if you installed NIS support on your system?

Oh, you're right. I was thinking NDIS for some reason. Probably the distribution does not support NIS and/or does not enable it in their Python builds.
Post reply on HN