Fwd: [Nipy-devel] attributes vs. traits
Brian Hawthorne
brian.lee.hawthorne at gmail.com
Mon May 22 04:10:37 CDT 2006
---------- Forwarded message ----------
From: Jonathan Taylor <jonathan.taylor at stanford.edu>
Date: May 22, 2006 12:37 AM
Subject: Re: [Nipy-devel] attributes vs. traits
To: Brian Hawthorne <brian.lee.hawthorne at gmail.com>
i basically want to be able to use traits for some simple applications,
so i am ok with leaving them out of the core library (but i don't know
where the boundary between core and application should be set quite
yet... but neuroimaging.{image,reference} would definitely fall into
"core" in my mind)
i could live with a working "traitsbridge" but i have a feeling that it
might be a lot of work to get working in full generality. if the
attributes used in the core are simple enough, then i think this should
work fine (once i really get a feel for the attributes system). this
way, traits can be left out as a dependency of the "core" but may be
necessary for some applications. we could perhaps insist that any "core"
attributes be mappable to a trait through the traitsbridge. some obvious
ones
are all the standard python numeric types, as well as the basic numpy
array types, strings, tuples/lists of such objects, color/rgba?
while this would mean that
we would not use all of the attributes' functionality in core objects,
neither would we use all of traits' functionality in core and we could
consider our core objects "strongly" typed in pure python. this does
seems a little unpythonic, though.
another worry i have is inheritance: unless the traitsbridge is quite
general, then i would worry about trying to "bridge" attributed
subclasses. following my line of argument above, this might suggest that
our core objects should be so fundamental that they shouldn't need to be
subclassed by users which sounds a little presumptuous. on the other
hand, if they subclass them and use attributes that can pass over the
bridge, then nothing is lost.
on another note, i have no idea how much work this is .... brian?
if we do restrict "core attributes" then we might also consider an
"hdf5dump" on top of a "traitsbridge" so the objects can be dumped to
disc transparently. enforcing simple attributes to ensure meaningful
hdf5 dumps does sound like a good argument for strongly types core
objects....
-- jonathan
Brian Hawthorne wrote:
>
>
> On 5/21/06, *Jonathan Taylor* <jonathan.taylor at stanford.edu
> <mailto:jonathan.taylor at stanford.edu>> wrote:
>
> more thoughts:
>
> i) i realize that properties are built-in in python, but do
> properties/attributes have any of the additional functionality that
> traits has, i.e. is there any possibility of easily popping this into
> something that will create GUIs to edit attributes? if not, we would
> likely have to do some of this ourselves and i don't think this is the
> best way to spend our time. in any case, i don't want to spend my time
> doing this, but i {\em would} like to be able to make "mini
> applications", i.e. not really production level, but useful for myself
> and a handful of other people.
>
>
> this is where the "traitsbridge" i mentioned would come in, allowing us
> to leverage the best part of traits without having to implement it
> ourselves.
>
>
> ii) the first google hit on "python properties" has nothing to do with
> python....
> the second is an ad for a book, the fifth is a real estate site
> (related
> to the first, i believe) and the 7th and 8th point to mails dated
> august
> 2002.... that said, i don't see much "momentum" for properties in
> python. on the other hand, the top two hits on "python traits" are
> about
> enthought's traits, but the 4th is about a snake. that said, i don't
> know how helpful google is in this respect.
>
>
> good point about the google hits! (i obviously didn't bother to read
> them...)
> as far as momentum, i guess i was thinking that you couldn't really
> get more
> momentous than being incorporated into the language proper.
>
> iii) i think the point about the "scientific python community" vs.
> the
> "python community" is important. to my eyes, much of the core (and
> interesting) work in the scientific python community is focused around
> enthought and i really like a lot of things that i saw / heard
> them talk
> about at scipy, in that i could immediately see how a lot of them
> could
> be useful.
> enthought's traits page (http://code.enthought.com/traits/) describes
> traits as "a big deal" that has revolutionized the mental model
> they use
> for programming....
>
>
> that's how enthought describes traits... i do believe that they're
> building some cool
> stuff with traits; i just think we can do better. by not providing a
> readonly trait,
> they encourage rampant object modification, which becomes a barrier to
> scalability.
> and by not providing a simple delegation mechanism which is easy to
> remember (attributes.deferto),
> they encourage duplication of state in object assemblies, another
> scalability barrier
> and source of bugs (which incidentally, is exacerbated by the
> ubiquitous object
> modification pattern).
>
> iv) about eggs: we are almost surely going to have some extension code
> (especially when the orsay group's contributions start ramping up), so
> we will likely have to distribute that, too.....
>
>
> good point.
>
> in my opinion, our project needs more focus on the science. for
> instance, i would like us to spend more time focusing on prototyping
> things like "ts_diagnostics" that i hacked out at the last
> mini-sprint.
>
>
> definitely agreed. i think think the reason that's not happening is
> that the code is difficult and not self-explanatory.
> that's why i've been spending most of my effort on cleaning and
> simplification. i'm
> looking at it as an investment that will pay off by enabling other
> developers to jump in
> and work on the science without having to tear their hair out
> comprehending the
> core libraries. (or maybe that's just me :)
>
> it won't be the end of the world if we favor traits. if enthought can
> use them effectively, then so can we.
> my honest recommendation is go with attributes (or something
> similar). i wrote that because i felt that traits was a bad influence on
> the code, for the reasons noted above and others, like general
> clutter, and poor ergonomics (an api should
> fit your brain the way a good tool fits your hand). the existing
> attribute-hosting classes will play nicely with
> trait-hosting classes (and attributes can even be used on classes
> which have traits as well), so they could simply
> be left alone, or easily moved back to traits for the sake of consistency.
>
> - brian
>
>
>
> Brian Hawthorne wrote:
>
> > Hi,
> >
> > i'm sorry about the extra traffic -- i just don't quite get the
> > attributes issue.
> >
> >
> > No need to be sorry; this is a discussion that needs to happen, not
> > just on this project, but in the scientific python community in
> > general (since that is enthought's target audience).
> >
> > first question: where does the module attributes.py come from?
> >
> >
> > I wrote it; and the protocols module too which it uses for
> (duck)type
> > checking.
> >
> >
> > 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
> > -------------------
> >
> >
> > That comment was just a note to myself saying: "fix this, it
> should be
> > restricted to a tuple or int"
> > It's fixed now and the line reads:
> >
> > class label (readonly): implements=(tuple,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)?
> >
> >
> > Metaclasses are a bit of python black magic which allows one to
> > control how the parts of a class declaration are used to
> construct the
> > class object. Metaclasses can be used to implement a kind of
> > functionality which is sometimes referred to as aspect-oriented
> > programming.
> > Aspect-oriented programming is a pattern for consolidating
> > "cross-cutting concerns" (not very self explanatory, I know). An
> > example of a cross-cutting concern would be a need to record or
> count
> > every method call on every class, along with what arguments were
> > passed to each method on each call. This sort of magic (if
> > implemented with a metaclass) would be broken by inheriting from
> > HasTraits, because HasTraits uses its own metaclass to perform the
> > traits magic. Since the attribute system extends built-in python
> > properties, it is not necessary to customize the host class in order
> > for it to support attributes.
> >
> >
> > 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.
> >
> >
> > Here's how a single attribute definition can be shared by multiple
> > host classes:
> >
> > class label (attribute): implements=str
> >
> > class Foo (object):
> > foolabel = label
> >
> > class Bar (object):
> > barlabel = label
> >
> > f = Foo()
> > b = Bar()
> > f.foolabel = "somestring" # ok
> > b.barlabel = "someotherstring" # also ok
> > f.foolabel = 10 # error
> > b.barlabel = 15 # error
> >
> > Another way to do this, using attribute cloning, which provides a
> > (possibly customized) copy of an attribute, can be seen in the
> > SamplingGrid definition, where the attributes parcelmap and
> parcelseq
> > are clones of the same attributes on ParcelIterator, except they
> are
> > modified to be settable:
> >
>
http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/neuroimaging/reference/grid.py
> <
http://projects.scipy.org/neuroimaging/ni/browser/ni/trunk/lib/neuroimaging/reference/grid.py
>
> > The SamplingGrid definition also demonstrates the nice attribute
> > delegation mechanism (using the deferto function). Here a grid
> > delegates to its mapping any requests to set, get, or del an
> attribute
> > called "input_coords" or "output_coords" (rather than maintain
> its own
> > separate copies of those state variables).
> >
> > 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)?
> >
> >
> > Aside from technical practicalities or asthetics, I think the
> issue of
> > community support really is one of the most important questions.
> > Since the attributes system is just a very thin extension of
> built-in
> > properties, the real question isn't attributes vs. traits, but
> > properties vs traits. Maybe it's just me... but I personally feel
> > uncomfortable relying so heavily on a huge legacy codebase from a
> > single corporation instead of the mainline of python development,
> > which is supported by python's worldwide community. The traits
> > library is in the unstable position of reimplementing a fairly
> > sophisticated chunk of functionality which is now built into the
> > python language. I think the momentum can only be with properties,
> > and therefore this project (*any* project) will be in a much more
> > strategic long-term position if we align with the mainstream of
> python
> > development. Quick google searches for "python properties" and
> > "python traits" return 4.75M and 1.5M hits respectively.
> >
> > I took a look at the endo output you posted. It looks pretty
> good; I
> > especially like the expandable trees. It didn't quite know what
> to do
> > with the attributes (which are properties), so that's a core
> language
> > feature that's not handled very well. Epydoc output is
> formatted to
> > mimic the javadoc format ( http://neuroimaging.scipy.org/api/),
> which,
> > while it may not be the best, is at least familiar to many
> > programmers. Epydoc also generates pdfs, and the upcoming
> release has
> > some really sweet graph building features:
> >
>
http://epydoc.sourceforge.net/api/epydoc.docwriter.dotgraph-module.html.
> > Also, I can install epydoc by typing "yum install epydoc". Nipy
> > installation needs to become a snap at some point, which means users
> > must not be required to hunt down and manually install
> scipy-distutils
> > and traits. We could package them for different platforms and
> > maintain our
> > own repos, requiring users to install directly from our repos (which
> > would at least be easier for them than manual installation). Or, we
> > could distribute eggs (which I think is a good idea regardless), and
> > bundle traits in our distribution egg (but this may require us to
> > maintain eggs for multiple platforms, since traits is not pure
> > python). Either way it's a lot of extra work for us...
> > We could also try to convince mainstream package repos to
> include traits.
> >
> > Anyone else on the list like to join the fray? :)
> >
> > - Brian
>
>
> --
>
------------------------------------------------------------------------
> 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 <http://www-stat.stanford.edu/%7Ejtaylo>
> 390 Serra Mall
> Stanford, CA 94305
>
>
--
------------------------------------------------------------------------
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 HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/nipy-devel/attachments/20060522/0cf50afa/attachment-0002.html
More information about the Nipy-devel
mailing list