Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose removal of unused arguments in decode methods #3165

Open
j-t-1 opened this issue Mar 3, 2025 · 0 comments
Open

Propose removal of unused arguments in decode methods #3165

j-t-1 opened this issue Mar 3, 2025 · 0 comments
Labels
is-maintenance Anything that is just internal: Simplifying code, syntax changes, updating docs, speed improvements needs-discussion The PR/issue needs more discussion before we can continue

Comments

@j-t-1
Copy link
Contributor

j-t-1 commented Mar 3, 2025

Four of the ten pypdf class filters have, but do not need, a decode_parms argument in their decode methods:

ASCIIHexDecode
ASCII85Decode
RunLengthDecode
JPXDecode

The rationale for having unused decode_parms is so external code has a uniform interface for filters. However, their existence tends to make the code less self explanatory.

Benefits of removing these:

Follows the design principle of moving semantics out of comments into code. The function signature will be more self contained, not relying on a comment explaining that one of the arguments is unused.

Coding to external library users who may not even use a uniform interface, complicates our interfaces. We do not use decode_parms in function decode_stream_data (which calls most of the filters) when it is unused, suggesting uniformity is not overly useful here.

Because all filter class decode methods have **kwargs: Any, any 3rd party code that does break can be fixed simply by ensuring decode_parms= is explicitly used when calling decode.

@stefan6419846 stefan6419846 added needs-discussion The PR/issue needs more discussion before we can continue is-maintenance Anything that is just internal: Simplifying code, syntax changes, updating docs, speed improvements labels Mar 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is-maintenance Anything that is just internal: Simplifying code, syntax changes, updating docs, speed improvements needs-discussion The PR/issue needs more discussion before we can continue
Projects
None yet
Development

No branches or pull requests

2 participants