Conversation
…ing transcripts and construct the Gene objects later
There was a problem hiding this comment.
Should raise_on_error be in the VariantAnnotator constructor instead of peppered across different methods?
There was a problem hiding this comment.
The most common use case is VariantCollection which uses VariantAnnotator under the hood. Not sure how to economize on raise_on_error since you'll need one arg in VariantCollection and another in VariantAnnotator.
There was a problem hiding this comment.
Yeah, I figured VariantCollection would pass it through to VariantAnnotator. The constructor just felt more appropriate to me, based on knowing far less about the code than you do.
There was a problem hiding this comment.
The constructor feels a little clumsier to me since the typical usecase seems to be:
- Construct
variant_collection = VariantCollection(some_vcf_path) - Call
variant_collection.variant_effects() - Encounter an error
- Decide the error is irrelevant
- Call
variant_collection.variant_effects(raise_on_error=False)to ignore the error
Having to create a new VariantCollection seems like a very minor hassle but it also doesn't have a clear payoff.
|
A few comments, but generally looks good to me! |
…ions collect effect annotation errors in dictionary, only look up overlapping...
... transcripts and construct the Gene objects later