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? -- Chris > > > I probably should have been more grandiose in my initial efforts; I'll > rectify that immediately and give you something a bit nicer. > > -> - Regarding nomenclature, I prefer the simple and mathematically > -> precise term "intervals" over the more ambiguous term "blocks". At > -> first I misunderstood what you meant by "Parse blast records into > -> ungapped blocks"; I would suggest instead "Parse blast hits into > -> aligned intervals". > > *shrug* that's fine by me. > > 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 -~----------~----~----~----~------~----~------~--~---
