Expose return_errors parameter to Python wrapper APIs. #618
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
axxel
requested changes
Sep 14, 2023
I don't see anything awkward with this approach at all. That is exactly how the c++ API works and if the caller is not interested in erroneous symbols, then they can simply leave the |
By default errors will not be returned. When requested, results with errors will only be returned when possible barcodes were found.
4ef3817 to
73761c0
Compare
|
Made fixes, pushed a rebased version of the branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creating this draft PR based on discussion in #617. I've tried to keep the API compatible with defaults reflecting existing behavior. I'm not super familiar with pybind and if there were specific doc patterns you'd prefer so hopefully what I've done is reasonable.
One challenge is since existing APIs return
Nonewhen there's no match (regardless of errors), withreturn_errors=Truewe have a somewhat awkward mode where it could returnNone(nothing at all found) or a result with errors (something found, but errors occurred). This forces callers in this mode to check twice for a clean scan result viaif result is not None and result.valid. I'm not super excited about this, but seemed like the least bad way without changing the API completely (like a separate function).By default errors will not be returned (so API compatible with defaults). When errors are requested, results with errors will only be returned when possible barcodes were found.