GeezerVison is showing github.com — Formally mark deprecated items in threading for removal in 3.21 · Issue #154205 · python/cpython
Formally mark deprecated items in threading for removal in 3.21 #154205DescriptionFeature or enhancement
Proposal:
Several camelCase names in the threading module have been marked with DeprecationWarnings since 3.10. (they are replaced by snake_case names and in some cases with properties rather than getter/setter functions) However, they have never had a removal version set.
I propose to mark these for removal in 3.21 and will prepare a PR to do so.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
Activityhugovk commented on Jul 20, 2026 This was originally deprecated in #87889 / #25174 in 3.10.
That PR was going to schedule removal in 3.12, but it was left open-ended due to too many projects still using the old names:
#87889 (comment)
Please can you check how many of the popular PyPI packages still use them? See https://hugovk.dev/blog/2022/how-to-search-5000-python-projects/. A GitHub search can also help gauge use.
Removal in 3.21 in 2032 is probably okay, and a deadline in the warning can prompt action; but would be good to have an idea of how widespread use is now and we can review again before actual removal. If there are projects still using the 2.5 name, PRs to upgrade would be helpful. jepler commented on Jul 20, 2026 ContributorAuthor More actions I downloaded the top 15000 files and searched with the following pattern:
'\b(\.notifyAll\(|\.isSet\(|activeCount\(\)|\.setDaemon\(|\.isDaemon\(\)|\.setName\(|\.getName\(\))\b'.
Result: Found 653 matching lines in 151 projects.
I think there are many false positives particularly for setName (371 hits across 45 packages) -- however there are a substantial number of hits for setDaemon which I think is less likely to be a false positive (194 across 100 packages).
setDaemon is a small number compared to hits for \.daemon =, 2656 matching lines in 789 projects. So deprecated uses are 7% of all uses but approximately 11% of packages using one or the other are still using the deprecated version.
ambv commented on Jul 22, 2026 Didn't we agree to stop breaking stuff like this? It wins us nothing. There's no advantage to removing the deprecated methods. Happy to be proven wrong, but this just seems disruptive for no actual maintenance gain.
You cannot see all the proprietary code at companies and how this will add to their churn while upgrading to Python 3.21 in the future. jepler commented on Jul 27, 2026 ContributorAuthor More actions I'm happy to drop this and any further "future deprecation" -> "scheduled deprecation" activities, if that's not how things are supposed to work. Thanks for responding kindly to my efforts even when they are misdirected. picnixz commented on Jul 28, 2026
Didn't we agree to stop breaking stuff like this? It wins us nothing
It depends I think. We did remove some symtable methods even if they were deprecated not long ago and we are also removing C API functions because it simplifies the code and avoids errors.
If we did agree to stop breaking stuff, I believe this should be documented and clarified somewhere. We should also explain what the scope is as otherwise it would never be possible to just remove deprecated APIs (we did remove dead batteries after all).
We also decided to sometimes make the removal to really force people make the transition (or report the impossibility thereof) I think. jepler commented on Oct 29, 2026 ContributorAuthor More actions The consensus seemed to be that this was undesirable churn. Thanks, reviewers & commenters. terryjreedy commented on Oct 29, 2026 Removing duplication makes a module easier to learn and use. Moving duplications to a separate section in the docs, rather than leaving them scattered throughout the docs, can serve the same purpose.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|