[Nipy-devel] attributes vs. traits

[Brian Hawthorne]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060520/3937adba/attachment-0002.html