Repository navigation
Formally mark deprecated items in threading for removal in 3.21 #154205
Description
Activity
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:
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.
Reacted by Stan UlbrychI 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 forsetDaemonwhich I think is less likely to be a false positive (194 across 100 packages).setDaemonis 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.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.
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.
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.
Feature or enhancement
Proposal:
Several camelCase names in the
threadingmodule 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