Skip to content

annotationlib: Improve test coverage #141174

Description

@dr-carlos

Feature or enhancement

Proposal:

The existing test suite for annotationlib is good, but there is still a decent amount of line/branch coverage missing. coverage.py reports 75% coverage, but this is mostly the library is already imported somewhere in coverage.py, so all global statements are marked as 'missing'.

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

Activity

  1. dr-carlos commented on Nov 9, 2025

    @dr-carlos
    ContributorAuthor

    Currently there is no coverage for the 'else' case in _build_closure():

    if i < len(freevars):
    name = freevars[i]
    else:
    name = "__cell__"

    But I'm not sure what conditions would cause __closure__ and __code__.co_freevars to be different lengths.
    Git blame says that @JelleZijlstra wrote this code, is there a particular object you'd expect to behave this way?

    The only other place in the stdlib where both are used together is inspect.getclosurevars(), which simply zips the closure and freevars together:

    cpython/Lib/inspect.py

    Lines 1503 to 1509 in 14c6222

    if func.__closure__ is None:
    nonlocal_vars = {}
    else:
    nonlocal_vars = {
    var : cell.cell_contents
    for var, cell in zip(code.co_freevars, func.__closure__)
    }

  2. JelleZijlstra commented on Nov 10, 2025

    @JelleZijlstra
    Member

    I think that could only happen with a manually constructed code object (or if there's a bug in the compiler). I wrote it that way to make the code robust to this case, but it might have been better to throw an error instead if the lengths mismatch.

  3. added a commit that references this issue on Nov 10, 2025
  4. added a commit that references this issue on Nov 10, 2025
  5. added a commit that references this issue on Nov 10, 2025
  6. added 2 commits that reference this issue on Nov 10, 2025
  7. added a commit that references this issue on Nov 10, 2025
  8. added a commit that references this issue on Nov 10, 2025
  9. added a commit that references this issue on Nov 10, 2025
  10. added a commit that references this issue on Nov 10, 2025
  11. added a commit that references this issue on Nov 10, 2025
  12. 11 remaining items

  13. dr-carlos commented on Aug 12, 2026

    @dr-carlos
    ContributorAuthor

    Probaly! Haven't looked at the tests recently, so will double-check over the next day.

  14. added 6 commits that reference this issue on Aug 13, 2026
  15. dr-carlos commented on Aug 13, 2026

    @dr-carlos
    ContributorAuthor

    Triage: Can this be clsoed as completed?

    It's completed, for now, until new features get added to annotationlib which aren't tested properly.
    But at that point it should be related to the specific feature, not to annotationlib as a whole, so I'll close this issue.

  16. added 3 commits that reference this issue on Aug 14, 2026
  17. added a commit that references this issue on Aug 19, 2026
  18. added 2 commits that reference this issue on Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions