On Tue, May 26, 2009 at 06:55:50AM -0700, Istvan Albert wrote: -> On May 26, 2:57?am, Christopher Lee <l...@chem.ucla.edu> wrote: -> -> > - blastx et al. forced me to make the code more general; I wouldn't ? -> > have done it otherwise. ?Your feeling that this generalization is ? -> > premature could thus be interpreted three different ways: -> -> I think that if an experienced programmer like Titus has a problem -> understanding how a function works, 99% of the target population will -> have even less to go on. My own opinion on the general complexity of -> many tools in pygr is that they are caused by 'internalizing' a lot of -> features. That leads to tge creation of monolithic blocks that take -> too many different arguments, many not even listed in the function -> signature (thos that are captured from **kwargs). -> -> I think a better approach rely more on chaining functions and partial -> composition as done in more functional type programming.
I'll answer Chris's e-mail here as well -- yes, exactly. Chaining functions, in particular, would help simplify matters. I like (generally, *really* like) the existing functionality, but understanding what any one piece of code does is quite difficult, and this makes debugging and extending tough. I think we can iteratively work towards something simpler. --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 -~----------~----~----~----~------~----~------~--~---
