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.
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
Small changes to simplify build_primer_pairs(). #89
Small changes to simplify build_primer_pairs(). #89
Changes from all commits
4d22e2b
febbefb
e503bf6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion Is this a good opportunity to refactor to make
amplicon
acached_property
, rather than mucking about with a private field andsetattr
?e.g.
and then no need for the post-init
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's questionable. For better or worse, PrimerPair relies on the checks in
calculate_amplicon_span()
to enforce that the pairing makes sense ... so we could make it a cached property and the still have a post_init that accesses it, or replicate the checks ... or separate the checks into yet another function. None of which seem obviously better.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really like to remove
_amplicon
as a "private" field.As a consequence of the current implementation, both
asdict()
andfields()
return a field that isn't accepted by the class constructor. This is unusual behavior and requires the user to remember and manually remove the field.Could we make
amplicon
acached_property
, and update the post-init checks to reference that property? That protects all the cases I'm aware of motivating the current implementation:amplicon
"attribute".amplicon
is still derived from the input primers.As a bonus, it removes the need to use
setattr
(currently necessary because we're trying to mutate a frozen dataclass after instantiation).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried ... but failed. Changed it to a cached property and tried calling it from post_init() to run the validation. Now I get this in tests, which is super unhelpful and I'm not sure why:
Going to merge without making the change, and we can circle back to it separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add validation for primer overlap.
Current check only verifies start positions. Also validate that left primer doesn't overlap significantly with right primer.
Add this check after the existing validation:
📝 Committable suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note I usually try to use
pytest.mark.parametrize
to parallelize test execution as much as possible.Tests exit after the first failed assertion, so if you bundle test cases in a single test, you run the risk of obscuring later failures. If you parametrize, you hit as many failures as possible in a single test run, and don't find yourself stuck in a loop of addressing one test case, running the test suite, and discovering a previously hidden failure.
I usually have one test parametrized over "good" cases, with each test case paired with its expected output, and one test parametrized over "bad" cases, where each case is expected to raise an exception.
Since here the
span
is the primary variable being manipulated by each case, I'd write something like the following:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is, to me, a stylistic thing, and I come down very strongly on the other side. I almost never use
pytest.mark.parametrize
because I personally find that it makes tests less maintainable, harder to read etc.If the tests aren't as simple as these, then I tend to break them up into multiple test functions.