[Nipy-devel] Re: traitswrap

[Jonathan Taylor]

i think a useable traitswrap is a little more complicated because we are 
now talking about trait editors which is already in the UI part of traits.

this solution would seem to work for things that are of truly standard 
python types (i.e. int, float, str) but would not give the desired 
behaviour for more complicated objects like ndarrays.

the limiting step is the sentence:
    "as long as its attributes ... have types that can be mapped to 
traits editors"

try the following (if you have traits.ui working -- the current svn tree 
works for me if i run setup_numpy.py in "enthought/src/lib/enthought", 
though i think i had to manually change some version number somewhere 
along the line because it wasn't the true svn version number that was 
being read on import):

------------------------------------------



import enthought.traits.ui
from enthought.traits import *
import numpy as N

class Test1(HasTraits):
    x = Trait(N.ndarray)
    ax = Trait(N.zeros((4,5)))
    y = Trait(float)
    z = Trait(43.)
    w = Trait(Float)

   
a = Test1(x=N.zeros((4,5)))
a.configure_traits()

class Test2(HasTraits):
    x = Array(shape=(4,None))

b = Test2(x=N.zeros((4,5)))
b.configure_traits()

b.x = N.zeros((4,3))
b.configure_traits()


# NOTE: trying "b.x = N.zeros((5,3))" will fail because shape must be 
(4,*)....
# so the array trait has extra control over the shape of the array or
# typecode, etc


------------------------------------------
the first example the default trait editor is useless, i.e. traits' 
editors are not smart enough to guess that the array editor should come 
up for 'x' but it does guess correctly for the floats. in the second you 
first get a 4x5 array to edit, then a 4x3 array. other examples where 
this can be a problem are for colors (traits has some color editors)....

we could try to enumerate the problematic cases so that we get the 
behaviour we want for some attributes, but this makes the traitswrap 
layer start sounding more complicated.

further, the default traits editors are not that pretty. for production 
code, we would want want to use the "views" and perhaps the "vet" tool 
to interactively design a traits editor. i suppose this could be done 
with the "traitswrapped" object, though.

another issue to consider is that it is not clear to me whether setting 
the traits of
traitswrap(attributey) sets the attributes of attributey: this needs to 
be considered for the "mode" of traits editing, i.e. whether it is 
"live" or not.

-- jonathan

Brian Hawthorne wrote:

> hey,
> just wanted to point out that with something like the wrapper sketched 
> below, you could use traits to edit the attributes *any* random python 
> object, as long as its attributes (using that word in the general 
> sense ;) have types that can be mapped to traits editors.  i think 
> that would be a pretty cool utility to have... 
>
>     regarding the bridge, i was imagining something like this (rough
>     sketch):
>     ---------------------------------------
>     from attributes import attribute
>     from enthought.traits import HasTraits, Trait
>
>     class WrapperTrait (Trait):
>         # this is where some work would be
>         def __init__(self, name, types): pass
>
>     def traitforval(name, val):
>         return WrapperTrait(name, (type(val),))
>
>     def traitforatt(att):
>         return WrapperTrait(att.name <http://att.name>, att.implements)
>
>     def attsof(obj):
>         return [(name,getattr(obj,name)) for name in dir(obj)]
>
>     def traitswrap(obj):
>         newtraits = {}
>
>         # collect traits for unmanaged attributes
>         newtraits.update([(name,traitforval(name,val)) for name,val in
>     vars(obj)]):
>
>         # collect traits for managed attributes
>         newtraits.update([(name,traitforatt(att)) for name,att in
>     attsof(obj)]\
>                           if issubclass(att, attribute)):
>        
>         def __init__(self, obj): self._wrappedobject = obj
>         newtraits["__init__"] = __init__
>         return type("TraitsProxy", (HasTraits,), newtraits)(obj)
>     ------------------------------------------
>
>     then in practice, we would use the traitswrap function to return a
>     HasTraits object with traits corresponding to the attributes of
>     the wrapped object.  for example, if you want to edit your object
>     "attributey", do this:
>
>     traitswrap(attributey).configure_traits()
>
>     in the above implementation sketch, the work would go into the
>     WrapperTrait (maybe a trait factory, not a trait subclass), which
>     would know how to map attribute types to trait types, and overload
>     trait getting/setting functionality to delegate to the underlying
>     wrapped object.  not knowing the traits internals at this time, i
>     can't say exactly how that would be done, but it shouldn't be too
>     hard.
>

-- 
------------------------------------------------------------------------
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
390 Serra Mall
Stanford, CA 94305