On May 28, 2009, at 1:09 PM, C. Titus Brown wrote:
> > First, here's a minor update to tests/.gitignore to ignore formatdb > output files: > > http://github.com/ctb/pygr/commit/6dba4bbb963195f928c5fc38c5dea2f47609ad48 > > It's in 'ctb_for_commit' at git://github.com/ctb/pygr.git. Thanks! Pushed to master. > Second, I tried pulling BlastHitParser into BlastHitParser (which > parses > BLAST output) and BlastHitsToBlocksParser (which extracts ungapped > blocks for use in NLMSA construction). I think the result makes > sense. > Take a look: > > http://github.com/ctb/pygr/commit/a53f279b4f97fadcf54fa805c4e670cd09f5565e > > Branch 'ctb_blast' at git://github.com/ctb/pygr.git. > > Let me know what you think. In general I like the idea of breaking up "monolithic" classes into cleaner modules of function. In this case I don't think I have understood what your purpose was, and how this usefully subdivides the functionality. The docstrings for the split classes don't give much of an explanation. A few questions: - Are you trying to make BlastHitParser a base class that *must* be extended before it becomes useful? I don't understand the value of giving it a parse_file() method, but then making that method just yield self. At best this seems like an internal interface, not something you would expose to users. Can you explain what the usage case for BlastHitParser is? - 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". In summary, I agree with subdividing into distinct classes for distinct purposes, but haven't yet understood the usage case for your BlastHitParser. Cheers, Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
