follow up on config file

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

The observer pattern would certainly be useful, delegation probably as
well.

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

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.

JDH

Hi. Here are a couple thoughts on the problem:
(1) Can we come up with a list of what capabilities we want the config library to do? I think it will be difficult to come to a definite plan without some sort of specs. Currently the prototype uses traits-lite to act as a sentinal to check that the assignment is valid. So if assignment-validation is all that is required, it seems a very small subsection of the Traits package.
(2) Using the traits package does have several difficulties: (a) currently it is difficult to find much written about it (I did not know it existed until you pointed it out), (b) it's API is currently changing (?), (c) will this require people to download and install SciPy as well? Or will it be distributed as a separate library?
(3) I agree. I think the current prototype framework will not need more than a couple hours of work to allow either method. Because of this, perhaps it's best to go the traits-lite route, until exactly what is happening with Traits2 becomes clear .. as long as we can make sure the main API doesn't change, it shouldn't affect the end user.
(4) One last thought. Maybe if we can spec out exactly what is required of whatever Traits package we use, we can provide a wrapper API so either one can be used. We can prefer the Traits package, but if it is not used, we can instead use our lite version.

Abe

John Hunter wrote:

···

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

The observer pattern would certainly be useful, delegation probably as
well.

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

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.

JDH

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

John Hunter wrote:

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

The observer pattern would certainly be useful, delegation probably as
well.

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

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.

All well stated and with which I wholeheartedly agree. A lot of work
has gone into traits. I also agree that the gui aspect of it is not
something one would want to use until it was truly made multi-GUI
supported.

Perry