2 ms·

No matter how many maintainers there are, the policy to eagerly deprecate and quickly remove things is something common to all of stdlib. And I think that’s not

• notatallshaw 3y ago
  There has been a recent push to remove completely unmaintained modules with PEP 594, but the steering council has made it clear that PEP was an exception and all future module deprecations will have to be done on a case by case basis. The PEP 594 modules were discussed for well over two years before the PEP was accepted, and includes unmaintained modules that were technically deprecated as of Python 2.0. I also rarely see methods removed at all, which is why the utcnow one sticks out so sharply for myself and others. I can't reconcile this with the statement of "policy to eagerly deprecate and quickly remove things", but maybe you have some evidence? Further there is a clear path discussed on the Python board of how to move any pure Python modules to PyPI for any part of the community that wish to maintain them. In the earlier years of Python it was not a serious option to ask everyone to use third party libraries, but now for almost all use cases it is a reasonable option.