STY: Tweak _page.py

[j-t-1]

Use modern formatting.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.83%. Comparing base (a8016c9) to head (6c3fc65).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3370      +/-   ##
==========================================
- Coverage   96.83%   96.83%   -0.01%     
==========================================
  Files          54       54              
  Lines        9098     9097       -1     
  Branches     1664     1664              
==========================================
- Hits         8810     8809       -1     
  Misses        172      172              
  Partials      116      116              

☔ View full report in Codecov by Sentry.
📢 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]

I do not see a benefit of using f-strings with a workaround here to make them compatible with bytes.

[j-t-1]

It is more modern, and more readable. %d is decimal but not quick to understand at a glance.

[stefan6419846]

I do not see where this is more readable. What is harder to understand about %d?

[j-t-1]

Its not widely known that %d is decimal.

F-Strings:

Not only are they more readable, more concise, and less prone to error than other ways of formatting, but they are also faster!

https://github.com/ikamensh/flynt

[stefan6419846]

Its not widely known that %d is decimal.

I have doubts about this. This is the standard specifier for both the old and new string formatting (although it might be omitted with the new one) as well as for loggin.

The quote you are giving is talking about plain strings. We are talking about bytes here.

[j-t-1]

The string is implicitly converted to bytes? So it starts off as a string?

[stefan6419846]

The old string formatting supports bytes as well, possibly due to Python 2. With b"%d" % id(self), the integer value id(self) is converted to a binary sequence while using the %d format for the value. We do not need to know (or do not care) what Python does internally to get something like b"42" as the result.

Using f"{id(self)}".encode() or f"{id(self):d}".encode() (both of which are equivalent as well for this specific case) might return the same result, but will involve an extra conversion from string to bytes due to the .encode() call in the worst case.

[j-t-1]

Agree do not need to care about how its done modulo performance. Possibly no diffence in performance, or current method may be better.

For the numeric codes, the only difference between str and bytes (or bytearray) interpolation is that the results from these codes will be ASCII-encoded text, not unicode. In other words, for any numeric formatting code %x:

b"%x" % val

is equivalent to:

("%x" % val).encode("ascii")

PEP 461 – Adding % formatting to bytes and bytearray

Is this okay for us here? Need to check if we decode using ASCII as well.

[stefan6419846]

As we are talking about serializing an integer value here, the encoding should not matter.

[j-t-1]

You are correct, good call.

Although this PR would not change functionality, it is a newer style and provides more consistency in our codebase.

pypdf/pypdf/generic/_base.py

Lines 76 to 77 in 7e1140d

	def hash_value_data(self) -> bytes:
	return f"{self}".encode()