You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecate camelCase aliases from threading.py #87889
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.
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.
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.
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 :-)
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.
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.
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.
Activity
JelleZijlstra commentedon Apr 4, 2021
Followup from bpo-37804: deprecate the remaining camelCase aliases, such as threading.currentThread. PR coming soon.
rhettinger commentedon Apr 4, 2021
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 commentedon Apr 6, 2021
Raymond Hettinger:
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 commentedon Apr 7, 2021
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 commentedon Apr 12, 2021
New changeset 9825bdf by Jelle Zijlstra in branch 'master':
bpo-43723: Deprecate camelCase aliases from threading (GH-25174)
9825bdf
tiran commentedon Apr 12, 2021
The commit broke my PR #25329. You missed a call in asyncio tests.
tiran commentedon Apr 12, 2021
New changeset 95bbb33 by Christian Heimes in branch 'master':
bpo-43723: Fix deprecation error caused by thread.setDaemon() (GH-25361)
95bbb33
vstinner commentedon Apr 12, 2021
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:
Usually, warnings are not treated as errors. Thanks for fixing test_asyncio!
tiran commentedon Apr 12, 2021
Tests should treat any unhandled deprecation warnings as a test failure.
tirkarthi commentedon Apr 12, 2021
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 commentedon Apr 12, 2021
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 commentedon Apr 12, 2021
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 commentedon Apr 16, 2021
New changeset 56c76df by Terry Jan Reedy in branch '3.9':
[3.9] bpo-43723: Revert IDLE doc change (GH-25174)
56c76df
terryjreedy commentedon Apr 16, 2021
New changeset b405647 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-43723: Backport IDLE doc change (GH-25174)
b405647
miss-islington commentedon Apr 16, 2021
New changeset 582917f by Miss Islington (bot) in branch '3.8':
[3.9] bpo-43723: Revert IDLE doc change (GH-25174)
582917f
vstinner commentedon Apr 16, 2021
Oh. I didn't notice that b405647 was already merged.
After being rebased before the merge, 582917f became an empty change!
Use non-deprecated name for `notify_all`
Squashed commit of the following:
Use non-deprecated name for `notify_all`