[RavSinghChandan]

AnnotationFlag is an IntFlag, so naming both it and int would be redundant. The setter wraps the value in a NumberObject and the getter already normalises through AnnotationFlag, so an int round-trips — test_annotation_dictionary sets 123 directly and asserts it reads back.

Only the setter widens; the getter still returns AnnotationFlag.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.98%. Comparing base (4c8f707) to head (57e6959).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3997   +/-   ##
=======================================
  Coverage   97.98%   97.98%           
=======================================
  Files          57       57           
  Lines       11098    11098           
  Branches     2078     2078           
=======================================
  Hits        10874    10874           
  Misses        125      125           
  Partials       99       99           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stefan6419846]

Doesn't this cause confusion? I mean, we have this enumeration, thus I would prefer if users would pass proper enum values for better readability.

[RavSinghChandan]

Agreed, and looking again the confusion was already in the documentation rather than the type. The example set annotation.flags = 4 directly under a comment telling the reader to see AnnotationFlag for the other options, so it pointed at the enum while demonstrating a magic number.

I've reverted the annotation change and fixed that instead: the example now uses AnnotationFlag.PRINT, which is the 4 it spelled out before, and test_annotation_dictionary combines three flags rather than asserting on 123. pypdf/annotations/_base.py is untouched now.