[Nipy-devel] help with attributes

[Brian Hawthorne]

Hi,

i) I kind of like the idea that at some point I might be able to call
>
> x.configure_traits()
>
> sometime in the future.


There were a couple points I forgot to mention in my original post, and the
traits editing was one of them.  I think the interactive editing features
traits provides (either via traitsui or straight to the console) are the
major strong point of traits.  My thinking on this is that there's no need
to reimpliment this nice functionality, but to provide a thin
traits/attributes bridge which could be used for the purpose.  For example:

foo = SomeClassWithAttributes()
...
# now we want to use traits' nice editing features on foo
from traitsbridge import TraitsWrapper
TraitsWrapper(foo).configure_traits() # let the editing begin!

The TraitsWrapper would inherit from HasTraits and the instance created
above would have traits corresponding to each attribute of foo (ie it
proxies foo).  This would be done dynamically in a uniform way, and I don't
think it would be too hard to implement.

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?


Yes you definitely can.  The AnalyzeHeader under the
refactoring.analyzemodule provides a good example of the same scenario
using attributes:
http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/neuroimaging/refactoring/analyze.py
Specifically, the class corresponding to your TraitHandler subclass is
structfield (a subclass of attribute), defined in neuroimaging.image.formats
:
http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/neuroimaging/image/formats/__init__.py
This AnalyzeHeader class (and its companion AnalyzeImage) is also a good
"real world" example of attributes in action, and is used by the
analyze-header script (which can be used to repair corrupt headers).

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


import enthought.traits as traits
import numpy as N

class SetOnceReadOnlyTraitHandler(traits.TraitHandler):

    '''
    A set-once, read only trait.
    '''

    def __init__(self, trait):
        self._trait = trait
        self.nchange = 0

    def validate(self, object, name, value):
        self.nchange += 1
        if self.nchange <= 2:
            return self._trait.validate(object, name, value)
        else:
            self.error(object, name, value)

    def info(self):
        return 'a read only trait'

def SetOnceReadOnlyTrait(trait):
    validator = SetOnceReadOnlyTraitHandler
>
> (trait)
>     return traits.Trait(trait, validator)
>
> class Test(traits.HasTraits):
>
>     x = SetOnceReadOnlyTrait(traits.Float(4))
>
> ## d = Test()
> ## print d.x
> ## d.x = 'a'
>
> d = Test()
> d.x = 3
> d.x = 4
>

This would be accomplished with attributes as follows:

from attributes import readonly
class Test (object):
    class x (readonly): default=4.

d = Test()
d.x = 3.
d.y = 4.

This illustrates a different point which I meant to mention in the first
email: attribute declarations use the class keyword.  This can be confusing
if you're not expecting it, but it provides the code block necessary to
consolidate the components of the declaration, which I think is very
important.

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


I guess the choices would be: migrate traits to be properties (like
attributes), or write your own special documentation tool, which is what
enthought did.  Or convince Guido that traits should become a standard part
of python, so that standard doc generators would need to support them... but
I don't see that happening any time soon.

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060518/2e881719/attachment.html