[Biopython-dev] Quality scores (and per-letter-annotation) in a SeqRecord?

Peter biopython at maubp.freeserve.co.uk
Tue Feb 24 09:08:17 EST 2009


On Tue, Feb 24, 2009 at 1:04 PM, Leighton Pritchard <lpritc at scri.ac.uk> wrote:
>> Your code seems a little more complicated, but should work too.  It
>> would mean that if the parent SeqRecord's seq property was altered,
>> the per-letter-annotation dictionary would know the new length.  This
>> is better - but if someone did change the parent SeqRecord's seq, then
>> perhaps we should also automatically clear the per-letter-annotation?
>> We could do this by using a full property for the seq attribute, which
>> would also us to clear any existing per-letter-annotation by replacing
>> it with a new restricted dictionary using the new length.
>
> I can think of two particular incompatible situations here:
>
> 1) I change the parent SeqRecord sequence, by slicing it to a region I'm
> interested in.  I want to keep the per-symbol-annotation, but adjusted to
> the new sequence.

If you did this by my_record[50:100] (assuming we implement the
__getitem__ method, see Bug 2507), then my_record isn't changed -
you'd get a new SeqRecord back for the partial sequence, with the
appropriate per-symbol-annotation (by which I mean each
per-symbol-annotation sequence would have been sliced using [50:100]
to match, and a new dictionary created to hold these sub-sequences of
the per-symbol-annotation).  I'll try and upload a SeqRecord patch
that does this shortly...

> 2) I change the parent SeqRecord sequence by adding some more symbols to it.
> I've just destroyed the association between the per-symbol-annotation and my
> sequence without even realising it.  I'd prefer a warning that this is going
> to happen before it destroys my earlier work, so I can make the change in a
> duplicate SeqRecord object.

This situation could be caught by a set method for the SeqRecord seq
property (not implemented yet).  I was thinking this would silently
throw away the old per-symbol-annotation, but this could instead raise
an error (and make no changes), or issue a warning (but carry on).
Good point.

Peter



More information about the Biopython-dev mailing list