On Fri, May 29, 2009 at 02:25:36PM -0700, Christopher Lee wrote: -> On May 29, 2009, at 2:00 PM, C. Titus Brown wrote: -> -> > Right now, BlastHitParser can't easily be used outside of the -> > context of -> > pygr because of the way BlastHitParser.parse_file mingles parsing -> > logic -> > (if self.is_valid_hit() etc.) with return results. This is a first -> > attempt to pull those apart. -> -> Let's see if I'm understanding right. Are you advocating that parsing -> should only produce an abstract parse tree as an internal state, -> returning nothing to the caller? You want to separate one class that -> generates an internal parse tree, and another class that provides a -> method for returning results? And this makes it easier for others to -> write new subclasses returning results in a different form?
That would be one way to do it; here's something that's simpler than I thought possible: http://github.com/ctb/pygr/commits/ctb_blast2/ http://github.com/ctb/pygr/commit/d37c77b6f661731acb6441f31608a660eb7ca060 This will let people re-use BlastHitParser by simply overriding generate_intervals. Down the road we could refactor as I originally did, but it would be nice to have a concrete use inside of pygr for that, which we currently don't. cheers, --titus -- C. Titus Brown, c...@msu.edu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
