You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be helpful if OffTargetDetector did not require Oligo or PrimerPair objects as input.
The off-target detection does not use any of the primer-related metrics that appear on these classes (e.g. tm, penalty), and this design constraint makes it challenging to reuse this functionality in other contexts.
I think the detection methods could be re-written to accept strings (or string tuples, for pair checking) as input. We could also consider accepting a Protocol for any class that includes a sequence or bases attribute.
The text was updated successfully, but these errors were encountered:
My 2c is that this is likely an "and", not an "instead of". I would object to there being two sets of functions:
One that takes primers/primer pairs
One that takes just sequences (or pairs of sequences) as strings
However, long term I think it is useful to have functions that take the richer objects. There are features I'd like to implement in OffTargetDetector that would require them (or a much more complicated Protocol), including:
Filtering out the on target locations of primers when returning "off target" mappings
Being able to filter off-target mappings by thermodynamic properties (e.g. the off-target mapping's Tm is at least 10C lower than the on-target Tm)
The functions that take just strings would not be able to do this, but that doesn't mean we shouldn't have them as an alternative.
It'd be helpful if
OffTargetDetector
did not requireOligo
orPrimerPair
objects as input.The off-target detection does not use any of the primer-related metrics that appear on these classes (e.g.
tm
,penalty
), and this design constraint makes it challenging to reuse this functionality in other contexts.I think the detection methods could be re-written to accept strings (or string tuples, for pair checking) as input. We could also consider accepting a
Protocol
for any class that includes asequence
orbases
attribute.The text was updated successfully, but these errors were encountered: