[Nipy-devel] attributes vs. traits

[Fernando Perez]

On 5/22/06, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
> i just want to add another of my $0.02: i don't think traits are hard to
> master, and the docs have enough examples that i was up and running
> quite quickly...
>
> my guess about the reason that there is likely no built-in way to make a
> read-only trait (i.e. that all objects are over-writeable) is that they
> are thinking of "applications" instead of "library".

Sorry to jump in late, and with next-to-zero knowledge of the details,
not having used traits myself for any real project.  But I've been
reading this discussion with great interest, since I think it is a
very important one both for the nipy project, and possibly for other
scientific projects in the future.

A few points, in no particular order:

1. I think it would be a good idea to involve some of the enthought
guys in this discussion.  We could bridge over to envisage-dev, or
ping some of them personally.  While I am sure they are heavily
invested in traits, they are also very reasonable folks and will
probably have interesting things to contribute to this discussion.

In particular, I am very interested in the following: you seem to have
identified some 'sticky'  issues with Traits, such as the metaclass
inheritance problem pointed by Yann, the read-only issue, and a few
more.  I think it would be valuable to get input from the traits gurus
on whether these are really fundamental stumbling blocks (which they
may have workarounds for, but at least may be real), or if it's just a
matter of not having learned how to use them correctly (and if this is
a documentation/examples issue, it can be remedied).

I imagine that if a project such as nipy seriously considers /not/
using traits after a thorough discussion, Enthought would be
interested in knowing about it.  Having others study your (free) tools
and reject them is always an indicator that either the tools don't fit
other's problems as well as you thought, or they aren't explained in
an accessible enough manner.

2. All have agreed that the GUI part of traits is valuable, and the
running idea seems to be a bridge layer.  While that may be fine, I
start to worry about the never-ending onion: attributes < traitsbridge
< traits < pyface < wxpython < wxwidgets < gtk < ...  There's
beginning to be too many layers in there for me to be comfortable,
because I can imagine if anything goes wrong, /never/ being able to
really pin down the culprit.  Just a worry...

3. Memory/runtime overhead of Traits and attributes?  Just something
to keep in mind, not that I have any particular knowledge one way or
another.

4. Integration with Envisage/TVTK/...?  From what Prabhu says on the
mayavi list, tvtk is a lot more pleasant/efficient to code for than
plain vtk-python is.  I haven't done more than click-playing with
envisage, but it looks promising.  If traits is abandoned, do we lose
these benefits?  Can we have our cake an eat it too?

5. Meta: I think it would be a good idea to have a wiki page
summarizing some of this discussion, at least the key points, once
they gel a bit.  While I vastly prefer mailing lists for running
discussion, once a few points become somewhat 'frozen', I think wikis
are a good way of keeping a semi-static summary so people don't have
to crawl the archives every time they want some info on the problem
(while the archives remain available for all the gory/exact details).

Cheers,

f