[Yt-dev] Auto-registration of callbacks and change in Callback API

[david collins]

Under "for what it's worth"

One thing I stuck in uber (the "Dave's Lazy" object) was a callback
interface that took a list, and that list could be strings of pre
defined things ("GridLines","VelocityQuiver") or subclasses of
callbacks, and it would sort out if it was a subgrid class type, in
which case it would just deal with it, or if it was a pre-defined
string like "Grids" it would call the extant subgrid object, which
uber already knew about.
It also made it easy to add several callbacks to a plot at once.

So the use pattern would be like
sim = uber( args )
sim.callbacks = ["VelocityQuiver","GridLines", dave_callbacks.TimeInTitle() ]
sim.plot()

and it would make whatever plot you defined, and add all the callbacks
in the list at once.

That's probably not useful here, I think something a little more
sophisticated is in order, but that was my take to the same issue.  It
does have the problem of not auto-listing.

d.



On Thu, Mar 19, 2009 at 1:57 PM, david collins <antpuncher at gmail.com> wrote:
> I'd vote for two. If you have a dictionary of things, then I can do
> p.modify.keys()
> and figure out what options are available to me.
>
> It's a bit more cumbersome of an interface than 3.  I like 3 because
> the interface is really easy, which I strongly approve of.  But then I
> have to go somewhere else to figure out what modifications are
> available (contour, subgrids, Did you call that "Arrow Callback" or
> "Quiver Callback?" and so on) and its not as obvious how to extend
> that interface to user defined callbacks.
>
> It would be nice if adding new callbacks and using extant ones was all
> done in one place-- I see
>
> p.modify["NewThingI'mAdding"] = dave_callbacks.PrintTheTimeInTheTitleOfThePlot()
>
> as a potentially useful pattern that would fall right out of a
> dictionary type method, but not as obvious with the other two.  I use
> my own callbacks all the time, so I would like to be able to use them
> with whatever new interface comes up; and it would be nice for a new
> user to not have to learn one system for calling pre-existing
> callbacks, and another for adding one's own.
>
> This is a good idea, I like this direction.
> d.
>
> On Thu, Mar 19, 2009 at 11:04 AM, Matthew Turk <matthewturk at gmail.com> wrote:
>> Hi guys,
>>
>> I've been helping some people learn to use yt lately, and it is
>> becoming apparent to me that the plotting API might need some work.
>> I'm mostly okay with the way the PlotCollection stuff is handled (but
>> see http://yt.enzotools.org/ticket/158 for more on that) but the
>> callbacks specifically are not terribly intuitive.  The current API
>> is:
>>
>> p = pc.add_projection(...)
>> p.add_callback(ContourCallback("Temperature"))
>>
>> Currently the Callback metaclass auto-registers each callback
>> (http://yt.enzotools.org/browser/trunk/yt/raven/Callbacks.py#L38) so
>> that they get imported automatically in yt.mods
>> (http://yt.enzotools.org/browser/trunk/yt/mods.py#L55) but this can be
>> done in a substantially more straightforward fashion.  (However, the
>> AMRData subclasses are also nearly auto-registering, which is
>> something I intend to explore a bit more in the future.)
>>
>> I'd like to propose that each callback be given a static attribute
>> _type_name -- i.e., "contour", "quiver" etc, and then this be used to
>> access that particular callback type.  I'm torn, however, on how this
>> should be handled.  There are three main ways I've considered for
>> implementing this:
>>
>> ==
>> 1. Through a .modify(type_name, *args, **kwargs) command.  You would then do:
>>
>> p.modify("contour", "Temperature")
>>
>> for instance, and it would add that callback.
>>
>> This has the downside that, while we could provide docstrings for all
>> the possible callbacks, we would have to implement some introspection
>> to do so.  Not a huge deal, but somewhat annoying.
>>
>> 2. Through dictionary-style lookup, similar to DerivedQuantities:
>>
>> p.modify["contour"]("Temperature")
>>
>> this would allow us to have docstrings without any introspection.
>>
>> 3. Through the current style used for generating data objects from the
>> hierarchy:
>>
>> p.contour("Temperature")
>>
>> This would also give us docstrings for free.
>> ==
>>
>> What do you think?  The first appeals to me the strongest for
>> aesthetic reasons, but the third appeals to me on the grounds of ease
>> of use and understanding.  Does anyone have any strong feelings?  This
>> would all be handled via an auto-registry situation, so the means of
>> adding new callbacks would change, but only in that they would all
>> require _type_name .  Additionally, I see no reason to get rid of the
>> current p.add_callback(...) method, which is more general that we're
>> looking at here.
>>
>> -Matt
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>