Skip to content

Deprecate camelCase aliases from threading.py #87889

Description

@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']

    Activity

    1. JelleZijlstra commented on Apr 4, 2021

      @JelleZijlstra
      MemberAuthor

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

    2. self-assigned this
      on Apr 4, 2021
    3. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Apr 4, 2021
    4. self-assigned this
      on Apr 4, 2021
    5. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Apr 4, 2021
    6. rhettinger commented on Apr 4, 2021

      @rhettinger
      Contributor

      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.

    7. vstinner commented on Apr 6, 2021

      @vstinner
      Member

      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.

    8. tirkarthi commented on Apr 7, 2021

      @tirkarthi
      Member

      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.

    9. vstinner commented on Apr 12, 2021

      @vstinner
      Member

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

    10. tiran commented on Apr 12, 2021

      @tiran
      Member

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

    11. tiran commented on Apr 12, 2021

      @tiran
      Member

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

    12. vstinner commented on Apr 12, 2021

      @vstinner
      Member

      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!

    13. tiran commented on Apr 12, 2021

      @tiran
      Member

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

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

    14. tirkarthi commented on Apr 12, 2021

      @tirkarthi
      Member

      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

    15. vstinner commented on Apr 12, 2021

      @vstinner
      Member

      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.

    16. vstinner commented on Apr 12, 2021

      @vstinner
      Member

      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.

    17. terryjreedy commented on Apr 16, 2021

      @terryjreedy
      Member

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

    18. terryjreedy commented on Apr 16, 2021

      @terryjreedy
      Member

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

    19. miss-islington commented on Apr 16, 2021

      @miss-islington
      Contributor

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

    20. vstinner commented on Apr 16, 2021

      @vstinner
      Member

      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!

    21. transferred this issue fromon Apr 10, 2022
    22. added a commit that references this issue on Aug 26, 2022
    23. added a commit that references this issue on Oct 30, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    3.10 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions