Hi Alex, how much faster is your library processor than iterating over blasting all the sequences in the simple-minded approach?
I suspect that incorporating your library blast processor into the 0.8 release may be complicated by the fact that BlastDB itself is now deprecated. We refactored all the blast support functionality into a separate module (pygr.blast); BlastDB is retained only for backward compatibility. I'll have to look at your code to see exactly what it's assuming and how easily this could be "ported" to our new BlastMapping construct. I guess your processor could be made into a BlastMapping method. Then there is the issue of testing -- do you have (or could you write) a test suite that would test this thoroughly, that we could incorporate into our standard tests or megatests (if the tests would take too long or require resources too big to be incorporated in the standard release package)? FYI, I have summarized the blast refactoring in the Pygr Dev discussion group and also somewhat in the issue tracker. Unfortunately, I haven't updated the regular documentation yet, because Istvan changed our documentation format to Restructured Text, and we (I) have to convert all the existing docs (50,000 words worth) to REST before updating its content. The switch to REST seems like a great idea, but it has slowed the updating of the docs to reflect all the 0.8 changes. -- 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 -~----------~----~----~----~------~----~------~--~---
