[Biopython] Translation of partial codons
Iddo Friedberg
idoerg at gmail.com
Thu Mar 21 17:10:13 UTC 2013
Suggstions so far:
1. Raise an exception. This may cause code running on existing data to
change behavior. I.e. it ran before well on bad length sequences, but as of
the new code installtion, things will break.
2. Add a default length_check=True to the translate method. Again, this may
cause exiting code to behave differently wiht the same data once user
upgrades. Unless the user explicitly changes the call to
myseq.translate(length_check=False)
3. My suggestion: use length_check=False as default. Code behaves the same
as before, so no data-induced breakages. If the user wants to check length,
the explicitly pass a True value. So we give the option of checking length,
and retaining code-behavior legacy.
length_check, being an argument, does not need to be passed explicitly.
On Thu, Mar 21, 2013 at 12:56 PM, Martin Mokrejs <
mmokrejs at fold.natur.cuni.cz> wrote:
>
>
> Iddo Friedberg wrote:
> > Perhaps raising an exceptiob should be the default behavior. But I
> suggest the user can pass an argument lenghtcheck=False. In that case, an
> exception will not be raised.
>
>
> But if somebody has to adjust an existing python code and add the extra
> argument, it is better
> to make the check in his/her code right away, and either prepend/append
> N's to the string,
> or whatever else. I don't see much sense to introduce the extra argument
> at all. Existing
> code will break for good, and those affected will just fix their code. ;)
>
> Normally I wouldn't be so sure but in this case I am really fond of
> raising an exception.
> If the character is missing in front of the string due to
>
> s = myseq[start:stop]
>
> while user hasn't realized for slicing one has to adjust to
>
> s = myseq[start-1:stop]
>
> , a typical error I bet, then these people will just be glad to hit the
> exception, finally.
> ;-) Getting an answer in a wrong reading frame is really bad.
>
>
> Those who had one or two letters less on the right end won't care, except
> maybe when they realized
> they have lost the trailing nucleotide somewhere. Again, I bet a slicing
> issue will be the
> upstream problem.
>
> Martin
>
> >
> > Iddo Friedberg
> > http://iddo-friedberg.net/contact.html
> >
> >> On Mar 21, 2013 12:38 PM, "Peter Cock" <p.j.a.cock at googlemail.com<mailto:
> p.j.a.cock at googlemail.com>> wrote:
> >>
> >> On Thu, Mar 21, 2013 at 4:24 PM, Martin Mokrejs
> >> <mmokrejs at fold.natur.cuni.cz <mailto:mmokrejs at fold.natur.cuni.cz>>
> wrote:
> >> >
> >> > I agree tha...
> >>
> >> So that's a +1 for an explicit error from Martin.
> >>
> >> Similarly Pete Thorpe (off list) agreed an error would be useful, but
> >> suggested a new option to specifically request the current behaviour.
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> _______________________________________________
> >> Biopython mailing list - Biopython at lists.open-bio....
> >>
>
--
Iddo Friedberg
http://iddo-friedberg.net/contact.html
++++++++++[>+++>++++++>++++++++>++++++++++>+++++++++++<<<<<-]>>>>++++.>
++++++..----.<<<<++++++++++++++++++++++++++++.-----------..>>>+.-----.
.>-.<<<<--.>>>++.>+++.<+++.----.-.<++++++++++++++++++.>+.>.<++.<<<+.>>
>>----.<--.>++++++.<<<<------------------------------------.
More information about the Biopython
mailing list