[Biopython-dev] Working on Sequence deprecation

[Jeffrey Chang]

On Sat, 27 Jan 2001, Brad Chapman wrote:

> Hello all;
> I was working some this morning on deprecating Sequence.py (in favor
> of Andrew's Seq.py), which I think is on our to-do list for the next
> release.

Yes, great job!  Thanks a lot for doing this.

> I'd done a little bit of work on this earlier on Fasta.py, and I
> completed the job this morning and checked it in along with tests.

Good.  Peter Wilkinson is working on a solution for parsing the
description line better, with support for NCBI's formats.  This stuff
should be coming in in the next few weeks or so.


> I then grepped for other stuff that uses Sequence.py, and came up
> with:
>
> o Rebase and Gobase -- These contain SequenceParser classes, but
> either these are left over from a copy and paste or the
> _SequenceConsumer classes haven't been written yet, I guess. What
> is the plan for these? It doesn't seem like the data really fits into
> a sequence class, but I'm not sure.

Don't know.  These seem to be stub classes that haven't been implemented
yet.  What are your plans for them, Cayte?  Are they removeable?


> o SwissProt -- I changed the SequenceParser to a simple
> implementation that uses the SeqRecord and Seq classes. I didn't
> really go into anything complicated like SeqFeatures yet.
> The context diff for this is attached. It also has a fix for OX
> lines, which I think actually fixes my previous patch. I didn't
> realize there wasn't a test for SProt before in the regression tests,
> so my previous test didn't handle OX lines correctly on older files
> (ie. it bombs out if there isn't an OX line. I think the new one does
> it right). Sorry about that, I think this might have been
> the problem Andrew was talking about in his Martel tests.


Great.  Please check your patch in.

> I think this is it, and then nothing will use Sequence.py. Pretty
> exciting! What do people think? Ready for Sequence.py to go so we only
> have one sequence class?

Yes, definitely exciting.  It'll be nice to have a common object that all
these different formats can map into.


> Additionally, have we also thought about getting rid of the SeqIO
> directory? I think the current Fasta.py will do everything this does
> right now, so we might not need it any more. What do people think?

Let's leave the directory in for now, for future expansion.  Eventually,
we should have a function (like bioperl's) where the user can point SeqIO
to a sequence file, and it'll figure out how to parse it into a Seq class.

Jeff