[Nipy-devel] attributes vs. traits

[Jonathan Taylor]

more thoughts:

i) i realize that properties are built-in in python, but do 
properties/attributes have any of the additional functionality that 
traits has, i.e. is there any possibility of easily popping this into 
something that will create GUIs to edit attributes? if not, we would 
likely have to do some of this ourselves and i don't think this is the 
best way to spend our time. in any case, i don't want to spend my time 
doing this, but i {\em would} like to be able to make "mini 
applications", i.e. not really production level, but useful for myself 
and a handful of other people.

ii) the first google hit on "python properties" has nothing to do with 
python....
the second is an ad for a book, the fifth is a real estate site (related 
to the first, i believe) and the 7th and 8th point to mails dated august 
2002.... that said, i don't see much "momentum" for properties in 
python. on the other hand, the top two hits on "python traits" are about 
enthought's traits, but the 4th is about a snake. that said, i don't 
know how helpful google is in this respect.

iii) i think the point about the "scientific python community" vs. the 
"python community" is important. to my eyes, much of the core (and 
interesting) work in the scientific python community is focused around 
enthought and i really like a lot of things that i saw / heard them talk 
about at scipy, in that i could immediately see how a lot of them could 
be useful.
enthought's traits page (http://code.enthought.com/traits/) describes 
traits as "a big deal" that has revolutionized the mental model they use 
for programming....

iv) about eggs: we are almost surely going to have some extension code 
(especially when the orsay group's contributions start ramping up), so 
we will likely have to distribute that, too.....

v) about stability of installation for nipy, things have obviously been 
very volatile with numpy and scipy recently, but these will likely 
stabilize when numpy 1.0 is released. at that point, i think we can 
track regular releases of numpy/scipy.  our living on the "bleeding 
edge" and working with scipy has already had some advantages 
(particularly ndimage for resampling images). also, i should point out 
that enthought's main source tree now supports numpy building 
transparently so the main enthought branch has caught up with 
numpy/scipy's rapid pace over the past six months.

i guess what i am getting is that the main momentum i see in the 
"scientific python community" is focused around projects that enthought 
supports.... so i am willing to depend on them for traits, i.e. i am not 
worried about their holding traits for ransom.
at this point in our project, i feel we should be so lucky to have to 
worry about outlasting any major changes in traits.

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.

-- jonathan

Brian Hawthorne wrote:

> Hi,
>
>     i'm sorry about the extra traffic -- i just don't quite get the
>     attributes issue. 
>
>
> No need to be sorry; this is a discussion that needs to happen, not 
> just on this project, but in the scientific python community in 
> general (since that is enthought's target audience).
>
>     first question: where does the module attributes.py come from?
>
>
> I wrote it; and the protocols module too which it uses for (duck)type 
> checking.
>  
>
>     second question: i don't quite understand the validation mechanism....
>     for instance, in revision 413 this line appears:
>     -------------------------
>     class label (readonly): implements=(None,) # fix: can be tuple or int
>     -------------------
>
>
> That comment was just a note to myself saying: "fix this, it should be 
> restricted to a tuple or int"
> It's fixed now and the line reads:
>
> class label (readonly): implements=(tuple,int)
>
>     third question / point: not being a computer scientist, i am not
>     impressed by arguments about messing up my metaclass structure
>     (mainly because i have no idea what this means in practical
>     terms). is there a concrete example where this makes a difference
>     ("this" being to use attributes or traits)? 
>
>
> Metaclasses are a bit of python black magic which allows one to 
> control how the parts of a class declaration are used to construct the 
> class object.  Metaclasses can be used to implement a kind of 
> functionality which is sometimes referred to as aspect-oriented 
> programming.
> Aspect-oriented programming is a pattern for consolidating 
> "cross-cutting concerns" (not very self explanatory, I know).  An 
> example of a cross-cutting concern would be a need to record or count 
> every method call on every class, along with what arguments were 
> passed to each method on each call.  This sort of magic (if 
> implemented with a metaclass) would be broken by inheriting from 
> HasTraits, because HasTraits uses its own metaclass to perform the 
> traits magic.  Since the attribute system extends built-in python 
> properties, it is not necessary to customize the host class in order 
> for it to support attributes.
>  
>
>     one instance where i could see traits' behaviour making sense in
>     this regard is if there were many classes that were to have the
>     attribute "label" above ( i.e. that line would appear in many
>     class definitions). looking at the attributes examples,
>     it would seem that the "label" attribute in each class having such
>     an attribute would be an instance of a different class BUT by
>     reusing a trait, ( i.e. putting the "label" trait definition
>     outside the class definitions and putting the line "label = label"
>     inside each class definition), then it would seem to me like these
>     "label" traits are really
>     instances of the same class (which may be desirable). however, not
>     being a computer scientist, i may be muddled in my class/metaclass
>     hierarchy again.
>
>
> Here's how a single attribute definition can be shared by multiple 
> host classes:
>
> class label (attribute): implements=str
>
> class Foo (object):
>     foolabel = label
>
> class Bar (object):
>     barlabel = label
>
> f = Foo()
> b = Bar()
> f.foolabel = "somestring"  # ok
> b.barlabel = "someotherstring"  # also ok
> f.foolabel = 10 # error
> b.barlabel = 15 # error
>
> Another way to do this, using attribute cloning, which provides a 
> (possibly customized) copy of an attribute, can be seen in the 
> SamplingGrid definition, where the attributes parcelmap and parcelseq 
> are clones of the same attributes on ParcelIterator, except they are 
> modified to be settable: 
> http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/neuroimaging/reference/grid.py
> The SamplingGrid definition also demonstrates the nice attribute 
> delegation mechanism (using the deferto function).  Here a grid 
> delegates to its mapping any requests to set, get, or del an attribute 
> called "input_coords" or "output_coords" (rather than maintain its own 
> separate copies of those state variables).
>
>     overall question: if traits already has potential UI's for editing
>     values (or fitting right into envisage if we ever use it), and has
>     community support via enthought and its users, what do we gain by
>     going to attributes instead (perhaps at the cost of adding a
>     dependency for generating docs)? 
>
>
> Aside from technical practicalities or asthetics, I think the issue of 
> community support really is one of the most important questions.  
> Since the attributes system is just a very thin extension of built-in 
> properties, the real question isn't attributes vs. traits, but 
> properties vs traits.  Maybe it's just me... but I personally feel 
> uncomfortable relying so heavily on a huge legacy codebase from a 
> single corporation instead of the mainline of python development, 
> which is supported by python's worldwide community.  The traits 
> library is in the unstable position of reimplementing a fairly 
> sophisticated chunk of functionality which is now built into the 
> python language.  I think the momentum can only be with properties, 
> and therefore this project (*any* project) will be in a much more 
> strategic long-term position if we align with the mainstream of python 
> development.  Quick google searches for "python properties" and 
> "python traits" return 4.75M and 1.5M hits respectively.
>  
> I took a look at the endo output you posted.  It looks pretty good; I 
> especially like the expandable trees.  It didn't quite know what to do 
> with the attributes (which are properties), so that's a core language 
> feature that's not handled very well.  Epydoc output is formatted to 
> mimic the javadoc format ( http://neuroimaging.scipy.org/api/), which, 
> while it may not be the best, is at least familiar to many 
> programmers.  Epydoc also generates pdfs, and the upcoming release has 
> some really sweet graph building features:  
> http://epydoc.sourceforge.net/api/epydoc.docwriter.dotgraph-module.html.
> Also, I can install epydoc by typing "yum install epydoc".  Nipy 
> installation needs to become a snap at some point, which means users 
> must not be required to hunt down and manually install scipy-distutils 
> and traits.  We could package them for different platforms and 
> maintain our
> own repos, requiring users to install directly from our repos (which 
> would at least be easier for them than manual installation). Or, we 
> could distribute eggs (which I think is a good idea regardless), and 
> bundle traits in our distribution egg (but this may require us to 
> maintain eggs for multiple platforms, since traits is not pure 
> python).  Either way it's a lot of extra work for us...
> We could also try to convince mainstream package repos to include traits.
>
> Anyone else on the list like to join the fray?  :)
>
> - Brian


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