Fwd: [Nipy-devel] attributes vs. traits

[Karl Young]

>
>     in my opinion, our project needs more focus on the science. for
>     instance, i would like us to spend more time focusing on prototyping
>     things like "ts_diagnostics" that i hacked out at the last
>     mini-sprint.
>
>
> definitely agreed.  i think think the reason that's not happening is 
> that the code is difficult and not self-explanatory.
> that's why i've been spending most of my effort on cleaning and 
> simplification.  i'm
> looking at it as an investment that will pay off by enabling other 
> developers to jump in
> and work on the science without having to tear their hair out 
> comprehending the
> core libraries.  (or maybe that's just me :)
>
Sorry to not weigh in on the traits/attributes issue but I just don't 
have the knowledge to contribute anything useful (though I certainly am 
acquiring some as a result of the discussion !). But I couldn't help 
responding to this exchange. I completely agree with both points; NiPy 
ought to be about the science and Jonathan has already provided some 
nice stuff re. tools but Brian's also right in that I don't think the 
average neuroimager can currently just check out the code and either 
contribute a sub-package or start analyzing data as it stands. I think 
we really do first need some basic discussions and decisions, at least 
for morons like me, about the basic architecture of NiPy. I.e. details 
like traits/attributes are important but so are basic structure 
discussions. E.g. do we need to set up a basic image processing utility 
area where we'd dump some e.g. new smoothing algorithm or should we just 
put those in some sub-package utility area - if so how do we find what's 
available - what's the suggested procedure for extending existing 
classes,..., re. interface issues should we all try to inherit from some 
NiPy wx mother widget or go off and do our own thing per sub-package re. 
It seems to me that to make it eventually easy for scientists to use and 
contribute to NiPy somebody has to think about this stuff early on and 
it's probably good that someone (like Brian) with some software 
engineering savvy be in on it (hence Jarod's suggestion re. trying to 
hire a code architect - which I think is a good one so that scientists 
can worry about science and not about whether the package is designed in 
a way that makes it easy for other people to use). Despite being the 
greatest idea since sliced bread (IMHO) NiPy probably won't serve as 
much of a collaborative tool if it turns into a hodge podge of great but 
hard to use/find algorithms. Sorry for the hot air but I wouldn't mind a 
few more discussions about overall structural issues if anyone is so 
inclined; currently I'm happy to just play around with the code but 
before I would try to do something like adding some nonlinear 
registration code a little better road map would be handy (e.g. where, 
besides docstrings, could I drop in the info. that that functionality 
has been added, and where people would need to look to 
improve/extended/ignore it).    

-- 

Karl Young
Center for Imaging of Neurodegenerative Diseases, UCSF          
VA Medical Center (114M)              Phone:  (415) 221-4810 x3114  lab        
4150 Clement Street                   FAX:    (415) 668-2864
San Francisco, CA 94121               Email:  karl young at ucsf edu