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