[Nipy-devel] attributes vs. traits

[Yann Cointepas]

Hi,

I started to work with traits recently and I think there are several
problems that can justify the need of another system such as attributes:

1) Multiple inheritance.
Using traits requires to derive from HasTraits. Therefeore if you want to
add traits to one existing class, you must use multiple inheritance. But
multiple inheritance is not always possible in Python for classes
implemented in C (for more info look at "Multiple inheritance" section of
http://www.python.org/dev/peps/pep-0253/ ). HasTraits uses C API for its
metaclass and since "the metaclass of a derived class must be a (non-strict)
subclass of the metaclasses of all its bases" (Python error message), it is
impossible to inherit HasTraits and another class using C metaclass. I found
this problem with C++ classes wrapped with sip. Let's take a simple example:
it is impossible to find a way to inherit from HasTraits and QWidget (from
PyQt) because their metaclasses do not have the same "instance layout".

2) Runtime traits type access
Given an instance, traits API allow to get a list of all traits (instance
traits and class traits) but it appear to be difficult (impossible ?) to
access to the type of the trait, one can only get a CTrait instance and I
don't know how to distinguish traits.Int, traits.String, etc. from a CTrait
instance. But this information can be useful in several context. For
example, I need to serialize objects in an XML format and to build a Qt GUI
for editing objects with traits.

3) Traits order
It woul be very interesting to have the possibility to give an order to the
traits of an object. It is not really important for a strict Python usage
but becomes meaningfull for the GUI of complex objects or when using traits
to add types to a Python function (where parameter order is important).

I do not know much about attributes.py yet but I interested in using and/or
contributing to a system allowing to overcome some of the traits
difficulties. For my application, I choosed to build a "signature" system on
the top of traits to overcome issues 2) and 3).

      Yann


On 5/20/06, Jonathan Taylor <jonathan.taylor at stanford.edu> wrote:
>
> hi again,
>
> i'm sorry about the extra traffic -- i just don't quite get the
> attributes issue.
>
> first question: where does the module attributes.py come from?
>
> 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
>
> -------------------
>
> i have no idea how the "implements statement" relates to the comment "can
> be tuple or int": why is None automatically associated to an int?
>
> this may be an unfair question because maybe the comment is not meant to
> imply that the "implements" statement should be interpreted as a tuple or
> int. if this comment does not mean that, then how would one specify an
> attribute that can be a tuple or int?
>
> in traits this is quite clear to me: it would look like
>
> label = traits.Trait([traits.Tuple, traits.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)?
>
> 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.
>
> 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)?
>
> -- jonathan
>



-- 
Yann Cointepas            Tel: +33 1 69 86 78 52
CEA - SHFJ                  Fax: +33 1 69 86 77 86
4, place du General Leclerc
91401 Orsay Cedex France
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060520/b62d5231/attachment-0002.html