5 ms·

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 basical

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.

themadsens 5y ago
Arguing that opponents to removal "can just step up as maintainers" are completely bogus. As mentioned elsewhere, this is more about eroding trust in stdlib as a stable baseline. This is just the kind of thing that will teach people to not trust Python as a stable foundation. Also. If maintenance of aging modules becomes tiresome, maybe it is a strong hint to keep backwards compatibility in Python proper.
- munch117 5y ago
  Not at all bogus. If "eroding trust in stdlib as a stable baseline" is an important issue to you, then you can do something about it by helping provide the resources that allows old modules to be kept. Core language backwards compatibility is a non-issue. Approximately zero percent of maintenance costs go towards that.
  - qbasic_forever 5y ago
    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.
    - nitrogen 5y ago
      > 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."
      - qbasic_forever 5y ago
        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.
      - williamsmj 5y ago
        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=19948642, https://news.ycombinator.com/item?id=19985802 https://news.ycombinator.com/item?id=19985802.
- pas 5y ago
  > maybe it is a strong hint to keep backwards compatibility in Python proper. Or.. or, just consider that the community looked at the relevant trade offs and decided what it decided. If someone wants an old built-in module they can use an old python version.
mjw1007 5y ago
Looking at https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/61 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.
- qbasic_forever 5y ago
  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?

themadsens 5y ago

Arguing that opponents to removal "can just step up as maintainers" are completely bogus. As mentioned elsewhere, this is more about eroding trust in stdlib as a stable baseline. This is just the kind of thing that will teach people to not trust Python as a stable foundation. Also. If maintenance of aging modules becomes tiresome, maybe it is a strong hint to keep backwards compatibility in Python proper.

munch117 5y ago
Not at all bogus. If "eroding trust in stdlib as a stable baseline" is an important issue to you, then you can do something about it by helping provide the resources that allows old modules to be kept. Core language backwards compatibility is a non-issue. Approximately zero percent of maintenance costs go towards that.
- qbasic_forever 5y ago
  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.
  - nitrogen 5y ago
    > 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."
    - qbasic_forever 5y ago
      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.
    - williamsmj 5y ago
      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=19948642, https://news.ycombinator.com/item?id=19985802 https://news.ycombinator.com/item?id=19985802.
pas 5y ago
> maybe it is a strong hint to keep backwards compatibility in Python proper. Or.. or, just consider that the community looked at the relevant trade offs and decided what it decided. If someone wants an old built-in module they can use an old python version.

mjw1007 5y ago

Looking at https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/61 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.

qbasic_forever 5y ago
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?