Fwd: [Nipy-devel] attributes vs. traits

Jonathan Taylor jonathan.taylor at stanford.edu
Mon May 22 17:34:01 CDT 2006


I agree with Karl and Brian that the code as it is needs work. I just 
don't think that traits is the source of the problem: that would be 
me..... I think this period of going through the clunky but 
semi-functioning code I wrote was to be expected, but I just don't want 
us to get rid of traits because I used it poorly.

-- Jonathan

Karl Young wrote:

>
>>
>>     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).   


-- 
------------------------------------------------------------------------
I'm part of the Team in Training: please support our efforts for the
Leukemia and Lymphoma Society!

http://www.active.com/donate/tntsvmb/tntsvmbJTaylor

GO TEAM !!!

------------------------------------------------------------------------
Jonathan Taylor                           Tel:   650.723.9230
Dept. of Statistics                       Fax:   650.725.8977
Sequoia Hall, 137                         www-stat.stanford.edu/~jtaylo
390 Serra Mall
Stanford, CA 94305




More information about the Nipy-devel mailing list