[Nipy-devel] help with attributes

Thu May 18 12:30:41 CDT 2006

Hi everyone,

I have a few questions/points on this topic:

i) I kind of like the idea that at some point I might be able to call

x.configure_traits()

sometime in the future.

ii) I used a subclass of TraitHandler for the analyze header which I 
thought made a nice way to describe
the .hdr format. Can you do things like this easily with attributes?

iii) Attached is a function that can make a trait read-only -- though 
the function SetOnceReadOnlyTrait (bad name of course) has to have a 
CTrait instance and not a TraitFactory instance passed to it -- this 
could of course be fixed. Basically, it means you have to write 
something like Float(0) instead of Float. Also, I didn't change traits'
exception message....

As for the fact that traits is C vs. pure python for attributes -- I 
would say this problem has been solved because traits is pretty stable.

Documentation is important -- maybe there is a way to fix this problem 
with traits?

-- Jonathan

Brian Hawthorne wrote:

> Hi Jonathan (and list),
>
>     p.s. does attribute offer the same thing traits does? if yes,
>     should we
>     be using both? i am kind of used to traits by now...
>
>
> I've been planning to broach this subject on list for a while, but you 
> beat me to it!
> (What follows is rather long, but I'm hoping to generate some 
> discussion.)
>
> The attribute system does offer roughly the same sort of functionality 
> that traits provide.  Should we be using both?  Definitely not in the 
> long term, though they can certainly coexist in the codebase (not on 
> the same class) for however long is necessary.  My hope is that we can 
> migrate to attributes and that everyone will agree that's a good idea. 
> :)  Here's what I'm thinking:
>
> Traits was written before properties were added to python, as a way to 
> formally declare object attributes, enforce typing, and trap attribute 
> access events.  Properties take care of the formal declaration and the 
> access trapping; so given that alone, I would consider two thirds of 
> traits' functionality obsolete already.  Also, traits requires the 
> host class to inherit from HasTraits, potentially screwing with your 
> inheritance hierarchy, and definitely messing with your metaclass.  In 
> addition, HasTraits adds a huge number of attributes and methods to 
> the host class (aka "bloat"), making autogenerated documentation a 
> morass.  In addition, standard python documentation generators (pydoc, 
> epydoc) know how to play nice with properties, but generate 
> meaningless drivel when presented with traits, requiring the use of 
> enthought's own special documentation tool (another dependency -- yuck!).
>
> On the other hand, properties are annoying sometimes too:  no type 
> checking, the getter and setter funcs must be defined separately and 
> then passed to a property constructor (unless you're using lambdas, 
> but those can't be very big, plus they're ugly), properties don't know 
> their own names, and you can't access the property object itself in 
> the getters/setters.  This is where attributes come in.  Attributes 
> are more pythonic than traits because they are properties, and as such 
> are more "standard" than traits (eg, standard doc tools know what to 
> do with them).  Attributes are more strategically implemented because 
> they leverage properties instead of reimplementing the functionality 
> that properties provide.  In addition, as properties, attributes don't 
> require the host class to inherit from anything special.  Attributes 
> are more portable as well because they are implemented in pure python 
> with no C code (as traits has).  Attributes overcome the separation of 
> the components of a property declaration by providing a nested code 
> block (inside the host class definition) under which the getters and 
> setters etc. may be defined.  This allows the entire attribute 
> declaration to be performed in a single python statement, regardless 
> of how sophisticated it might be.  Needless to say, attributes know 
> their own names, and getters/setters receive a reference to the 
> attribute object itself in addition to the host class instance.  As 
> far as typing goes, attributes can be declared to implement a 
> protocol, rather than being
> restricted to a particular type, making them again more pythonic by 
> embracing "duck typing" (if it walks like a...).  Another useful 
> feature which I'm not sure if traits implements or not is a simple 
> access control mechanism (private vs public).  An attribute whose name 
> begins with an underscore can only be referred to inside a method of 
> its host class.  One final feature is dirt simple delegation, for when 
> you need
> some inheritance-like behaviour in an object graph instead of a class 
> tree.
>
> When I sat down with Matthew Brett a few weeks ago to start diggin in 
> the code, the very first thing we wanted to do was make a read-only 
> trait (actually set-once, then read-only).  It must be easy... but 
> after skimming the documentation for 10 minutes, we still didn't know 
> how to do that!  We did find a trait called ReadOnly, but it was a red 
> herring (behaved more like a constant).  So that was the initial 
> impetus to implement attributes.  That leads to another discussion I'd 
> like to have soon:  copy vs modify.  I'll save that for another 
> posting though ;)
>
> The attributes module's main docstring contains a doctest which serves 
> as a mini-tutorial:
> http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/attributes.py 
> <http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/attributes.py>
>
> If you've read this far then hopefully you have an opinion; I'd like 
> to hear it!
> (traits vs attributes line count is below.)
>
> Cheers,
> Brian
>
> In the traits-1.0.2 source dir:
> % wc -l $(find enthought/traits/ -name "*[.py,.c]")
>  13292 total
>
> In the nipy main project dir:
> % wc -l lib/protocols.py lib/attributes.py
>  401 total
>
> A whopping 97% code reduction!
>

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: readonly.py
Url: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060518/414b8821/attachment.pl 