Recommend closing resolved or non-actionable issues (oldest-first batch, 2004–2007) #150566

Activity

1. citadelgrad

   changed the title [-]Recommend closing resolved or non-actionable issues (oldest-first batch)[/-] [+]Recommend closing resolved or non-actionable issues (oldest-first batch, 2004–2007)[/+] on May 28, 2026
2. terryjreedy commented on May 29, 2026

   

   terryjreedy

   on May 29, 2026

   Member

   More actions

   Thank you for the work. I asked on our core dev discord triage channel about how we handle this and anything similar.
3. picnixz

   added

   infraCI, GitHub Actions, buildbots, Dependabot, etc.CI, GitHub Actions, buildbots, Dependabot, etc.

   on May 29, 2026
4. serhiy-storchaka commented on May 29, 2026

   

   serhiy-storchaka

   on May 29, 2026

   Member

   More actions

   Please don't close re and tkinter issues. They all are at the bottom of my backlog.

   The email package has many issues, and we should only close old issues until we sure that they are fixed. For example, while convert() was removed, the replacement was not ideal, and there are many remnants that mix the old and the new approach. It should be carefully reviewed and rewritten.

   imaplib also has many design issues. I worked on the mentioned issue, but have not finished the solution yet, it is hard, and requires many other changes to be done.

   urllib.parse still very far from ideal. I planned several steps, with adding new options, deprecations, and breaking compatibility when time comes. It will take years until we can say that the main issues are fixed.

   Cookies support is in terrible state. I closed some old issues few weeks ago, but these modules require redesign, I have not even started it. I need the issues to be open to see the whole image.

   Transparent gzip compression and redirection are nice to have features. If anybody provide PRs, this will be appreciated. But this an be not easy.

   In general, I am against bulk-closing issues. They should be considered on a case-by-case basis.
5. citadelgrad commented on May 29, 2026

   

   citadelgrad

   on May 29, 2026

   Author

   More actions

   @serhiy-storchaka Keeping them open indefinitely doesn't fix the problem; it just adds to the cognitive load of backlog triage and obscures active, high-priority issues. Closing them doesn't erase anything all info is perfectly preserved.

   This is a step toward a cleaner, more manageable tracker.
6. terryjreedy commented on May 30, 2026

   

   terryjreedy

   on May 30, 2026

   Member

   More actions

   Closing may not erase an issue, but it does mostly hide it by erasing 'someone still wants to consider this'. The default display for projects is all open issues, possible sorted by some topic. I have IDLE issues sorted by 'Topic', which has 22 ordered options. The GH search page allows selection by various criteria, but in particular by open/closed.
7. devdanzin commented on May 30, 2026

   

   devdanzin

   on May 30, 2026

   Member

   More actions

   I like the idea of bulk-analyzing old issues, but only if:

   • You eagerly take triager and code developer opinions about which issues to close into account.
   • Code reorganization and last update time are de-priorized (that is, some code moving places doesn't signal an issue should be closed, nor does the last time someone bumped an issue).

   I'm generally against closing due to staleness: closing because something got fixed, or no further information was offered by the reporter, or some deprecation making the change unlikely, etc., all make sense to me. Closing because no one took a look at the issue in a long time feels less than ideal.

   Here's some issue-by-issue feedback, if you're using some sort of agent/LLM for the analysis I'd like you to give it this feedback to see whether the conclusions change.

   [ ] Use getaddrinfo() in urllib2.py for IPv6 support #44672 (opened Mar 7, 2007) — Use getaddrinfo() in urllib2.py for IPv6 support

   I still see socket.gethostbyname() in Lib/urllib/request.py, are those uses OK or should they also be converted to getaddrinfo? If they should, the issue should be kept open.

   [ ] Patch for [ 735515 ] urllib2 should cache 301 redir #45217 (opened Jul 18, 2007) — Patch for urllib2 should cache 301 redirects

   Seems like a reasonable feature request to me, the fact that nobody else has asked for it (the other related issue, #38478, is the same report) makes closing an option, but I'd vote to keep it open. Sounds like a good issue for first time contributors.

   [ ] RFC 2965 BaseCookie does not support "$Port" #44019 (opened Sep 24, 2006) — RFC 2965 BaseCookie does not support $Port

   A core developer has asked for cookie issues to remain open.

   [ ] Alternate RFC 3986 compliant URI parsing module #43453 (opened Jun 4, 2006) — Alternate RFC 3986 compliant URI parsing module

   A core developer has asked for URL parsing issues to remain open.

   [ ] transparent gzip compression in urllib #43521 (opened Jun 19, 2006) — Transparent gzip compression in urllib

   Looks like a reasonable feature request to me, and has had some effort poured into it, as well as positive evaluations. I'd vote to keep it open.

   [ ] SRE engine should release the GIL when/if possible #42625 (opened Nov 25, 2005) — SRE engine should release the GIL when/if possible

   A core developer has asked for re issues to remain open.

   [ ] New sequences for Unicode groups and block ranges needed #43715 (opened Jul 25, 2006) — New Unicode group and block range sequences for re

   A core developer has asked for re issues to remain open (though this one does seem closable to me).

   [ ] email/charset.py convert() patch #42985 (opened Mar 6, 2006) — email/charset.py convert() patch

   A core developer has asked for email issues to remain open.

   [ ] patch smtplib:when SMTPDataError, rset crashes with sslerror #43311 (opened May 3, 2006) — smtplib: RSET crashes with SSLError after SMTPDataError

   Reportedly still an issue, coming up with a reproducer would be valuable. I vote to keep open.

   [ ] imaplib: incorrect quoting in commands #40038 (opened Mar 16, 2004) — imaplib: incorrect quoting in commands

   A core developer has asked for imaplib issues to remain open.

   [ ] wait_variable hangs at exit #40440 (opened Jun 23, 2004) — wait_variable hangs at exit

   A core developer has asked for tkinter issues to remain open (but this one does look closable to me).

   [ ] Prefix search is filesystem-centric #41525 (opened Feb 4, 2005) — Prefix search is filesystem-centric

   Looks like a reasonable report, but needs some effort to become actionable. Vote to keep open.

   [ ] Export more libreadline API functions #41788 (opened Apr 1, 2005) — Export more libreadline API functions

   The mentioned missing functions are still missing in main, vote to keep open.

   [ ] Simplying Tkinter's event loop #42255 (opened Aug 4, 2005) — Simplifying Tkinter's event loop

   A core developer has asked for tkinter issues to remain open.

   [ ] Tkdnd mouse cursor handling patch #43699 (opened Jul 20, 2006) — Tkdnd mouse cursor handling patch

   A core developer has asked for tkinter issues to remain open.

   [ ] Added support for custom readline functions #44781 (opened Mar 28, 2007) — Added support for custom readline functions

   IMO subsumed by #41788, vote to close.

   [ ] POSIX capabilities support #44335 (opened Dec 13, 2006) — POSIX capabilities support

   A lot of effort seems necessary to revive this one, a major new feature as proposed requires a DPO discussion these days. Vote to close, unless someone wants to champion the feature and discussion.

   [ ] SocketServer.DatagramRequestHandler with empty response #45276 (opened Aug 4, 2007) — SocketServer.DatagramRequestHandler with empty response

   I've suggested closing this one before, vote for closing.

   [ ] mail message parsing glitch #44196 (opened Nov 5, 2006) — mail message parsing glitch

   A core developer has asked for email issues to remain open.

   [ ] filecmp.cmp's "shallow" option #42172 (opened Jul 8, 2005) — filecmp.cmp's "shallow" option documentation

   Actually not a purely documentation issue, has patch for tests, behavior and documentation. Vote to keep open.

   ---

   So I agree with closing 3 out of 20. That shouldn't discourage bulk analysis IMO, just inform it so that future review align more closely with what is wanted from core developers and triagers.

   If no one objects, I'm going to close #45276 and #44781 later tonight.

   👍React with 👍1Reacted by Scott Nixon
8. soreavis commented on Jul 19, 2026

   

   soreavis

   on Jul 19, 2026

   Last edited by soreavis

   Contributor

   More actions

   Since this list is still open, here's a roll-up of a full pass over all 22 issues, verified against main as of today (source reads plus a fresh build). Transparency first: the recent evidence comments on several of these issues are mine — I put the details (reproducers, source cites, and for #44672 a patch) on each issue where there was something concrete to add, and this comment is just the index tying them together.

   Verified fixed at main — closable as completed:

   • patch smtplib:when SMTPDataError, rset crashes with sslerror #43311 — the 2006 SSLError masking is gone (bpo-17498's _rset() + SSLError being an OSError subclass); TLS reproducer on the issue.
   • mail message parsing glitch #44196 — the folded Message-id: case round-trips idempotently under both policies since Parsing adds whitespace to the front of long headers #124452 (Nov 2024); reproducer on the issue.
   • imaplib: incorrect quoting in commands #40038 — already closed (fixed via gh-40038: Quote imaplib command arguments when necessary #152703, 2026-07-05).

   Superseded or already covered — closable:

   • New sequences for Unicode groups and block ranges needed #43715 — \p{...} landed in June via gh-95555: Support Unicode property escapes \p{...} in regular expressions #151969 under re should support \p{...} character properties #95555; the request lives there now.
   • Added support for custom readline functions #44781 — fully contained in Export more libreadline API functions #41788 (same rl_add_defun callback ask plus rl_on_new_line; the two were linked in 2016); nothing landed at main.
   • Alternate RFC 3986 compliant URI parsing module #43453 — the module was set aside by its author in 2010, and the surviving ask — mining its RFC 3986 test corpus into test_urlparse — turns out to be already done: the full section 5.4 set is covered there, and the remaining divergences are deliberate parser decisions (evidence on the issue).
   • filecmp.cmp's "shallow" option #42172 — the doc/behavior mismatch was fixed by bpo-42958: Update filecmp.cmp docs #27166 in 2021, and the hard-no-read behavior change itself was already declined then too (bpo-41354: Adjust filecmp.cmp() to match documentation #21580, closed in favor of the doc fix — details on the issue).
   • Prefix search is filesystem-centric #41525 — the 2005 zip-stdlib symptom is gone at tip: the zip became a prefix landmark on POSIX in 3.11 (bpo-45582: Port getpath[p].c to Python #29041), the remaining warning is deliberate with an opt-out, and the original availability question has stdlib answers now (evidence on the issue).

   Close already suggested above, nothing new since:

   • SocketServer.DatagramRequestHandler with empty response #45276 — still reproduces at tip but matches the 2016 working-as-intended read; the only leftover is the doc note suggested back then.
   • POSIX capabilities support #44335 — never implemented; one correction: PR WIP: bpo-1615158 : POSIX capabilities support (In a separate module) #15815 was closed unmerged in 2020 (the "2022" activity was the bpo migration).

   Keep open — actively being worked:

   • wait_variable hangs at exit #40440 — fix PR gh-40440: Add a timeout parameter to tkinter wait_variable() #152619 is open (currently needs a rebase).
   • httplib simply ignores CONTINUE #42550 — PR gh-42550: Add 'Expect: 100-Continue' support to httplib #133276 in review as a 3.16 feature.

   Keep open — held for maintainer plans in those areas:

   • RFC 2965 BaseCookie does not support "$Port" #44019 — RFC 2965 itself was obsoleted by RFC 6265 (which dropped $Port), but cookies are held for the redesign.
   • email/charset.py convert() patch #42985 — the 2006 patch targets convert(), removed in 2007; the area is held for the email charset rework.
   • Simplying Tkinter's event loop #42255 — depends on rejected bpo-1049855 and the approach was refuted in 2009; tkinter hold.
   • SRE engine should release the GIL when/if possible #42625 — confirmed the GIL is held for a whole match at tip (nothing releases it in Modules/_sre), declined before as too hard; free-threaded builds change the calculus anyway.

   Keep open — real work:

   • Use getaddrinfo() in urllib2.py for IPv6 support #44672 — HTTP is clean, but FTPHandler.ftp_open still pre-resolves IPv4-only ahead of an IPv6-capable ftplib; fix is dropping that line — the patch is up as gh-44672: Stop pre-resolving the FTP host in urllib.request #154192.
   • email package content-transfer-encoding behaviour changed #43702 — email.encoders still emit a duplicate Content-Transfer-Encoding header; one-line fix per encoder (details on the issue).
   • Patch for [ 735515 ] urllib2 should cache 301 redir #45217 — 301 caching still unimplemented (http_error_301 aliases the 302 handler); agree it fits a first-time contributor — the more so since the design was already settled in the 2010 review (off-by-default, confined to the redirect handler, cache chained redirects: bpo msg97282/msg97264, accepted in msg97293 but never implemented). One caution for whoever picks it up: the surviving attachment implements the shape that review rejected (cache state on OpenerDirector through a module-level global), so better to start fresh.
   • transparent gzip compression in urllib #43521 — still absent at tip; the blocker is one unmade design call (opt-in handler vs default-on in http.client) — a concrete answer is up as gh-43521: Add an opt-in gzip Content-Encoding handler to urllib.request #154197 (opt-in; the default-on flip is offered in the PR).
   • Export more libreadline API functions #41788 — the requested functions are still missing from Modules/readline.c; becomes the canonical readline issue if Added support for custom readline functions #44781 closes into it.
   • Tkdnd mouse cursor handling patch #43699 — half landed 2026-07-05 (cursor delay); the configurable-cursor half was explicitly declined in that PR.

   Net: 7 more look closable now (#43311, #44196, #43715, #44781, #43453, #42172, #41525), 2 match the closes already suggested (#45276, #44335), and the keep-opens each have a concrete, non-staleness reason above. The per-issue evidence comments are on #43311, #44196, #43715, #45276, #44781, #44672, #43702, #43521, #43453, #42172, and #41525.

   👍React with 👍1Reacted by Scott Nixon
9. terryjreedy commented on Jul 21, 2026

   

   terryjreedy

   on Jul 21, 2026

   Last edited by terryjreedy

   Member

   More actions

   @serhiy-storchaka [EDITED] A new reviewer has sorted the suggested closings into 7 likely closeable (either completed or superceded/duplicate) and the remainder to be left open. If you (and Claude) were to review the 'closable' items and quickly decide either way (leave open unless close is obviously correct), this omnibus issue could be closed, as there is no reason to have open a list of random issues that are and should remain open.
10. citadelgrad commented on Jul 22, 2026

    

    citadelgrad

    on Jul 22, 2026

    Author

    More actions

    Just trying to help clear the 5k+ backlog of issues.

    urllib2 is part of std lib of python2 which no longer receives updates. So why are we keeping the 45217 issue open?

    Make it make sense?!
11. soreavis commented on Jul 22, 2026

    

    soreavis

    on Jul 22, 2026

    Last edited by soreavis

    Contributor

    More actions

    @citadelgrad the name is what's dated — urllib2 became urllib.request in Python 3. The redirect handler is live at Lib/urllib/request.py:722 and still doesn't cache, so the 2007 request applies to current code.

    That's why the #45217 issue should stay open.

    👍React with 👍1Reacted by Scott Nixon
12. serhiy-storchaka commented on Jul 22, 2026

    

    serhiy-storchaka

    on Jul 22, 2026

    Member

    More actions

    Even if the issue is no longer reproduced with the Python 2 code, it can mean that the reproducer code should be updated to Python 3. I reopened such prematurely closed issues in past.

    👍React with 👍1Reacted by soreavis
13. citadelgrad

    closed this as completedon Aug 4, 2026