[Bioperl-l] Bio::SearchIO::hmmer hsp behaviour
cjfields at uiuc.edu
Thu Jun 29 09:27:00 EDT 2006
On Jun 29, 2006, at 2:02 AM, Sendu Bala wrote:
> Chris Fields wrote:
>> Personally, I don't think right now is the time to think about
>> this particular module, esp. since I find it essentially works. I
>> that energy is better spent elsewhere, such as SeqIO::genbank/
>> swiss/embl for
>> instance, or refactoring SearchIO::blast etc to use hashes instead of
>> objects to speed things up. Or creating something yourself. Or
>> doing what
>> you currently are doing (Bio::Map). In other words, areas where
>> use is
>> high, code is aging, and refactoring is more productive.
> Hmmer parsing happens to be important to me, in fact vital for my
> I've been using my own parser up till now, so didn't know what the
> Bioperl one was like. I'd like to use Bioperl for more things,
> preferably everything.
We're not deterring you from setting up your own parser, something
both Jason and I suggested. I just don't see what the major issue
is; hmmerpfam results never really contain the same number of hits
per query that BLAST does (I get at the very most 30-40 and that is
usually based on repeats). I believe the best place to spend this
energy first and foremost is fixing the bug.
>> I'll add that I'm not trying to dissuade you from trying to build
>> your own
>> variation of a SearchIO HMMER parser; by all means go ahead. The
>> above is
>> how I feel. You can build your own parser to do what you want;
>> you can even
>> base it off the current SearchIO HMMER parser and see if you can
>> set it up
>> to give you the results you want, using a different handler and so
>> on. Just
>> don't break the API or modify the current code based strictly on
>> what your
>> opinion of how it should work is. It was probably set up this way
>> for a
>> particular reason.
> Well, I don't like the idea of there being multiple SearchIO
> parsers for
> the same thing.
See, here's the thing: if the community-at-large decides to use your
version of the parser then, by default it will become the only HMMER
SearchIO parser and we'll deprecate the old one. I just don't think
this is the way I would go about it. Jason has mentioned that object
instantiation is a bigger issue with parsing (speed) than anything
else; why not, if you plan on doing this, set up a Handler to return
hashes, or do it completely under-the-hood? Have it be the 'new,
faster way to run SearchIO.' Don't rehash (pardon the bad pun) the
way things were esp. when proposals are out there to improve the
>> And, frankly, it's not up to the user when using code they didn't
>> You have to deal with it. Or code something yourself to do things
>> the way
>> you want. You have the power to do that; most bioperl users don't
>> b/c they probably don't understand the class structure and OO
>> nature of
>> Bioperl. It's just a matter of where you want to spend your
>> energy: dealing
>> with something that interests you or fixing other's people's
>> broken code.
> My original question was essentially: does doing it my way make sense?
> And implicitly: would doing it my way be of any harm? Ie. can I go
> and change how the parser reports results and groups them together? I
> don't think it will involve an API change, but the results it
> will obviously be very different.
And my point is that both ways make sense, at least to me (and it
sounds like to Jason though I could be wrong). Again, create a new
version of the parser based on what you want to do and accomplish.
Don't just modify something the community at-large uses based on your
whims. Make the changes to a new module and let the community
decide. As an example, BioPerl, for the longest time, had several
BLAST parsers; we directed everybody over to SearchIO and most people
seem to like it; hence the others are deprecated.
And changing the results returned by some could be considered
changing the API or a bug. If someone using this module has an
automated pipeline set up for annotation using Pfam, hmmpfam,
Bioperl, and a database, and their setup expects single model/domain
pairs, yeah, your changes will break that. Maybe small,
inconsequential even, but it's possible (and even true; many genome
annotation pipelines are set up exactly how I describe).
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign
More information about the Bioperl-l