Deprecate camelCase aliases from threading.py

[JelleZijlstra]

BPO	43723
Nosy	@rhettinger, @terryjreedy, @pitrou, @vstinner, @tiran, @JelleZijlstra, @miss-islington, @tirkarthi
PRs	bpo-43723: deprecate camelCase aliases from threading #25174 bpo-43723: Fix deprecation error caused by thread.setDaemon() (GH-25361) #25361 [3.9] bpo-43723: Backport IDLE doc change (GH-25174) #25432 [3.8] [3.9] bpo-43723: Revert IDLE doc change (GH-25174) #25433 [3.8] bpo-43723: Backport IDLE doc change (GH-25174) #25435

^{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 = 'https://github.com/JelleZijlstra'
closed_at = <Date 2021-04-12.12:07:13.169>
created_at = <Date 2021-04-04.01:01:50.964>
labels = ['library', '3.10']
title = 'Deprecate camelCase aliases from threading.py'
updated_at = <Date 2021-04-16.09:50:58.623>
user = 'https://github.com/JelleZijlstra'

bugs.python.org fields:

activity = <Date 2021-04-16.09:50:58.623>
actor = 'vstinner'
assignee = 'JelleZijlstra'
closed = True
closed_date = <Date 2021-04-12.12:07:13.169>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2021-04-04.01:01:50.964>
creator = 'JelleZijlstra'
dependencies = []
files = []
hgrepos = []
issue_num = 43723
keywords = ['patch']
message_count = 16.0
messages = ['390165', '390166', '390337', '390442', '390826', '390833', '390837', '390840', '390843', '390845', '390846', '390847', '391167', '391169', '391179', '391180']
nosy_count = 8.0
nosy_names = ['rhettinger', 'terry.reedy', 'pitrou', 'vstinner', 'christian.heimes', 'JelleZijlstra', 'miss-islington', 'xtreak']
pr_nums = ['25174', '25361', '25432', '25433', '25435']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue43723'
versions = ['Python 3.10']

[JelleZijlstra]

Followup from bpo-37804: deprecate the remaining camelCase aliases, such as threading.currentThread. PR coming soon.

[rhettinger]

I don't think there is any advantage in doing this. It will just break code that has worked for a very long time.

This is the reason that the logging module wasn't changed to more modern naming conventions.

[vstinner]

Raymond Hettinger:

I don't think there is any advantage in doing this. It will just break code that has worked for a very long time.

Do you mean code written for Python 2? Right, it's unfortunate that it became harder to write a single code base working on Python 2 and Python 2. But Python 2 had officially reached end of life in January 2020, and Python 3.0 changed threading method names 13 years ago (2008).

Deprecating and removing aliases are two different things. IMO deprecating is non-controversial, especially because DeprecationWarning is hidden by default.

Removing requires to estimate how many projects are impacted. On the top 4000 PyPI projects, I count 80 projects which still call currentThread() for example: that's significant. Example of projects: Twisted, pyuwsgi, PyQt5_sip, mod_wsgi, mercurial, lockfile, jupyterlab, gevent, etc. I didn't check if these projects call current_thread() on Python 3.

I would suggest to wait until the most popular PyPI projects no longer call deprecated methods before removing them.

I suggest to restrict the PR to deprecatation, and not plan removal yet.

[tirkarthi]

Just to add the last time isAlive was removed in favor of is_alive it was significant change enough that several libraries in Fedora packaging Python libraries and other open source code. The GitHub PR shows several projects that were affected and I linked to this PR while filing the fixes to relevant libraries.

#15225

There are still new reports of the isAlive change when people try to upgrade : https://github.com/search?l=Python&o=desc&q=isalive+is%3Aissue&s=updated&state=open&type=Issues

I would request to really weigh in the cost of doing this since at one point this will cause more burden when the aliases have to be removed in future hindering Python upgrades and the change just seems to unify the casing of the method names without helping the user here.

[vstinner]

New changeset 9825bdf by Jelle Zijlstra in branch 'master':
bpo-43723: Deprecate camelCase aliases from threading (GH-25174)
9825bdf

[tiran]

The commit broke my PR #25329. You missed a call in asyncio tests.

[tiran]

New changeset 95bbb33 by Christian Heimes in branch 'master':
bpo-43723: Fix deprecation error caused by thread.setDaemon() (GH-25361)
95bbb33

[vstinner]

Thanks Jelle Zijlstra, I merged your PR! I close issue.

Ok, aliases are now deprecated. If someone wants to actually remove the aliases, I suggest to help all projects still using them to fix their deprecation warnings:
https://bugs.python.org/issue43723#msg390337

For now, I prefer to not schedule the removal. There are too many projects using it. By the way, I'm surprised that this number, I expected that most projects switched since Python 2.6 :-)

Christian:

The commit broke my PR #25329

Usually, warnings are not treated as errors. Thanks for fixing test_asyncio!

[tiran]

Usually, warnings are not treated as errors. Thanks for fixing test_asyncio!

Tests should treat any unhandled deprecation warnings as a test failure.

[tirkarthi]

I opened a thread a year back on running tests with -Werror in CI. This issue still pops up when someone runs with -Wall and finds unhandled deprecation warnings.

https://discuss.python.org/t/run-test-suite-with-werror-on-ci/2333

[vstinner]

Tests should treat any unhandled deprecation warnings as a test failure.

libregrtest sets a sys.unraisablehook: a test is marked as "failed" if any "unraisable exception" is logged.

libregrtest might use a hook on warnings to do the same: log the warning, but mark the test as failed?

One issue that I had with libregrtest and sys.unraisablehook was that some "unraisable exception" was not logged in buildbot logs. I had to use sys.__stderr__ to ensure that the exception is logged. See regrtest_unraisable_hook() of test.libregrtest.utils.

It would be annoying to get a test marked as "FAILED" if the warning is not visible in logs :-(

---

Using -Werror on some CIs would be another option.

[vstinner]

Oh by the way, if someone wants to enhance libregrtest / our CI, please open a new issue ;-) I'm not interested so, I didn't open a new issue :-) Someone also once proposed to add a post-commit buildbot using -Werror. It may be enough.

[terryjreedy]

New changeset 56c76df by Terry Jan Reedy in branch '3.9':
[3.9] bpo-43723: Revert IDLE doc change (GH-25174)
56c76df

[terryjreedy]

New changeset b405647 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-43723: Backport IDLE doc change (GH-25174)
b405647

[miss-islington]

New changeset 582917f by Miss Islington (bot) in branch '3.8':
[3.9] bpo-43723: Revert IDLE doc change (GH-25174)
582917f

[vstinner]

New changeset 582917f by Miss Islington (bot) in branch '3.8':
[3.9] bpo-43723: Revert IDLE doc change (GH-25174)

Oh. I didn't notice that b405647 was already merged.

After being rebased before the merge, 582917f became an empty change!