[Bioperl-guts-l] [BioPerl - Bug #2979] (Feedback) Bio::SeqIO::multifasta

redmine at redmine.open-bio.org redmine at redmine.open-bio.org
Sun Mar 27 19:27:12 EDT 2011

Issue #2979 has been updated by Jason Stajich.

Status changed from New to Feedback
Priority changed from Normal to Low

I really don't see the point in this module and it would just add to confusion we already have with multiple ways to index and access Fasta formatted files. 
Why won't Bio::DB::Fasta work? That is a maintained and well tested module with several sophisticated interfaces which also are used as back-end to things like Gbrowse.  

The argument of not wanting build an index file is kind of a weak one, or at worst case you could add a feature to that module that would keep the index as in-memory only (can be done with DB_File DBs I believe).

Please provide some feedback or I think this will be marked as invalid.
Bug #2979: Bio::SeqIO::multifasta

Author: Jean-Marc Frigerio
Status: Feedback
Priority: Low
Assignee: Bioperl Guts
Category: Bio::SeqIO
Target version: unspecified


 I wrote and currently use a module I named Bio::SeqIO::multifasta, which is basically a copy of Bio::SeqIO::fasta plus a few methods:
 get_by_id(), get_by_order(), first_seq() and previous_seq()

It would need review, validation, tests (if accepted)  etc

I haven't looked enough in Bio::DB::Fasta and Bio::Index::Fasta for sure. My idea was to avoid creating index files and to only load in memory the pos() of each sequence in array and hash (hum hum assuming unique ids) and then use seek() to retrieve the sequence.
This works on filehandle and so on a data stream no ?

I think this way may be efficient for fasta file containing a fairly great number of short sequences.


You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here and login: http://redmine.open-bio.org

More information about the Bioperl-guts-l mailing list