If I'm not mistaken, those are the names that the Trait
> package used originally! They changed the name because of
> potential confusion with Python properties. Isn't that
> still an issue?
And I think we should seriously consider using enthought traits rather
than rolling our own. I understand that a C extension doesn't work
for ipython, but matplotlib has enough extension code that one extra
piece wouldn't hurt too much. I haven't had much too much luck with
the GUI component of traits -- it only works with WX currently and
even then it was flaky on OSX.
I'm not totally opposed to rolling our own traits-light (whatever we
call it) because its a basic application of properties, but we would
probably end up reinventing a fair amount that enthought has already
done, and my guess is there version will be faster, more feature rich
and better documented (they have about 100 page user's guide for
traits2). And we've been accused of failing to build on other
people's efforts in scipy and chaco, so I think we should be sensitive
to reinventing another wheel that enthought has put a lot of work
The observer pattern would certainly be useful, delegation probably as
We come full-circle back to the same point -- we would like to see a
free standing traits package outside of envisage and scipy distutils
that we could simply install w/o having to maintain a separate tree
that we factor out. This has been mentioned a few times, but I'll
bring this up on envisage dev again.
This would also smooth the path toward making matplotlib an envisage
Sorry if you feel pulled in many directions Abraham -- your work is
very nice and may be the right way to go. Whether we decide to use
your properties or enthought traits, the rc framework you've setup
appears to be readily usable with either.