Repository navigation
Deprecate camelCase aliases from threading.py #87889
Description
Activity
Followup from bpo-37804: deprecate the remaining camelCase aliases, such as threading.currentThread. PR coming soon.
- addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory3.10 (EOL)end of lifeend of life
on Apr 4, 2021 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on 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.
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.
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.
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.
The commit broke my PR #25329. You missed a call in asyncio tests.
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#msg390337For 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!
Usually, warnings are not treated as errors. Thanks for fixing test_asyncio!
Tests should treat any unhandled deprecation warnings as a test failure.
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
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.
- added a commit that references this issue
on Aug 21, 2022 - added a commit that references this issue
on Aug 26, 2022 - added a commit that references this issue
on Oct 30, 2022
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:
bugs.python.org fields: