Fwd: [Nipy-devel] attributes vs. traits

[Brian Hawthorne]

i meant to respond to the list:


On 5/21/06, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
>
> 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.


this is where the "traitsbridge" i mentioned would come in, allowing us
to leverage the best part of traits without having to implement it
ourselves.


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


good point about the google hits!  (i obviously didn't bother to read
them...)
as far as momentum, i guess i was thinking that you couldn't really get more

momentous than being incorporated into the language proper.

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


that's how enthought describes traits...  i do believe that they're building
some cool
stuff with traits; i just think we can do better.  by not providing a
readonly trait,
they encourage rampant object modification, which becomes a barrier to
scalability.
and by not providing a simple delegation mechanism which is easy to remember
(attributes.deferto),
they encourage duplication of state in object assemblies, another
scalability barrier
and source of bugs (which incidentally, is exacerbated by the ubiquitous
object
modification pattern).

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


good point.

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

it won't be the end of the world if we favor traits.  if enthought can use
them effectively, then so can we.
my honest recommendation is go with attributes (or something similar).  i
wrote that because i felt that traits was a bad influence on
the code, for the reasons noted above and others, like general clutter, and
poor ergonomics (an api should
fit your brain the way a good tool fits your hand).  the existing
attribute-hosting classes will play nicely with
trait-hosting classes (and attributes can even be used on classes which have
traits as well), so they could simply
be left alone, or easily moved back to traits for the sake of consistency.

- brian



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<http://www-stat.stanford.edu/%7Ejtaylo>
> 390 Serra Mall
> Stanford, CA 94305
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060522/faec51e3/attachment-0002.html