PEP 594 Removing dead batteries from stdlib

[aeros]

BPO	42611
Nosy	@terryjreedy, @tiran, @jkloth, @isidentical, @aeros
PRs	bpo-42611: PEP 594 - Remove asyncore, asynchat, and smptd from stdlib #23728

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-12-10.04:51:12.046>
labels = ['type-feature', 'library', '3.10']
title = 'PEP 594 Removing dead batteries from stdlib'
updated_at = <Date 2020-12-12.01:54:23.481>
user = 'https://github.com/aeros'

bugs.python.org fields:

activity = <Date 2020-12-12.01:54:23.481>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-12-10.04:51:12.046>
creator = 'aeros'
dependencies = []
files = []
hgrepos = []
issue_num = 42611
keywords = []
message_count = 2.0
messages = ['382815', '382898']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'christian.heimes', 'jkloth', 'BTaskaya', 'aeros']
pr_nums = ['23728']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue42611'
versions = ['Python 3.10']

[aeros]

This issue was created for the purpose of tracking any changes related to PEP-594 (Removing dead batteries from stdlib), and any relevant discussions about the modules being removed.

[terryjreedy]

Until a pep is approved, discussion of its ideas belong elsewhere; an issue is only needed for a proposed implementation Is PR 23728 purely for discussion leading to possible approval of the PEP, or for merging regardless of the PEP fate?

[arhadthedev]

Repurposing this issue for 3.13.

[hugovk]

I've made a start on removing the more straightforward ones in a branch.

Would it be better with all in one PR, as one PR per module, or somewhere in the middle with smaller batches?

[arhadthedev]

I would vote for the one PR per module option. It allows reviewers to not get lost with each removed module having:

• Python code
• tests
• documentation
• probably a C module
  • associated automake/Makefile and Visual Studio rules
  • also we need to check for _Py* functions added exclusively for the module and used nowhere else.

[arhadthedev]

Closing in favor of gh-104773.

[CAM-Gerlach]

Re-closing with the correct close state.