[yt-dev] Callbacks for the Plot Window

[Nathan Goldbaum]

I think the logic is that a dict pointing to functions makes the codebase a bit cleaner and prevents the proliferation of hardcoded alias functions that wrap a callback.

However, in python we can import MethodType which allows us to construct the callback alias functions at runtime based on the dict of callback functions.  This StackOverflow topic explains it pretty straightforwardly: http://stackoverflow.com/questions/962962/python-changing-methods-and-attributes-at-runtime

I'll try to get this working tonight before I go to bed :)

Cheers,

Nathan

On Jul 8, 2012, at 9:47 PM, Casey W. Stark wrote:

> +1 on Andrew's point. I like using yt interactively, but that behavior drives me crazy. If memory serves, numpy auto-imports so many things for this same reason.
> 
> - Casey
> 
> 
> On Sun, Jul 8, 2012 at 9:44 PM, Andrew Myers <atmyers at berkeley.edu> wrote:
> Data point: as someone used to using <TAB> and "?" in ipython to familiarize myself with new classes, I definitely found the current "dictionary of functions" thing a bit inconvenient / confusing when I first started to use yt. In addition to <TAB> not giving a list of available callbacks in the current code, I find that I can't do:
> 
> In [5]: p.modify["grids"]?
> Object `p.modify["grids"]` not found.
> 
> but instead have to do:
> 
> In [9]: func = p.modify["grids"]
> 
> In [10]: func?
> Type:           function
> Base Class:     <type 'function'>
> String Form:    <function GridBoundaryCallback at 0x43c65f0>
> Namespace:      Interactive
> File:           /u/atmyers/yt-x86_64/lib/python2.7/site-packages/yt-2.4dev-py2.7-linux-x86_64.egg/yt/visualization/plot_types.py
> Definition:     func(*args, **kwargs)
> Docstring:
>     <no docstring>
> Constructor Docstring:
>     Adds grid boundaries to a plot, optionally with *alpha*-blending.
>     Cuttoff for display is at *min_pix* wide.
>     *annotate* puts the grid id in the corner of the grid.  (Not so great in projections...)
> Call def:       func(self, plot)   
> 
> if I need to look up the argument list for one of the callbacks. Just my $0.02. 
> 
> -Andrew Myers
> 
> 
> On Sun, Jul 8, 2012 at 8:10 PM, Nathan Goldbaum <goldbaum at ucolick.org> wrote:
> Hi all,
> 
> Matt and I have been thinking about how to port the already existing callbacks to the new Plot Window plotting interface.  We've come down to two choices that we'd like to the put to the list to vote on.
> 
> The first choice is to leave the interface exactly the same and use dict-like access through a .modify member that hangs off the PlotWindow object.  So, for example, if you wanted to add grids to a plot, it would look something like this:
> 
> >> slc = SlicePlot(pf, 0, 'Density')
> >> slc.modify['grids']()
> 
> Alternatively, the callbacks could hang off of the plot window object as attributes:
> 
> >> slc = SlicePlot(pf, 0, 'Density')
> >> slc.annotate_grids()
> 
> Personally, I prefer the second choice since it leaves the list of annotations available at runtime.  In ipython, for example, I could say slc.annotate<tab> and then get a list of all of the available plot modifications for this object.
> 
> Both choices are about equally complicated syntactically since the attributes can be dynamically generated based on a list of available callbacks in plot_modifications.py.
> 
> If you have an opinion, please reply with a vote for your preferred option.
> 
> Cheers,
> 
> Nathan Goldbaum
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> 
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> 
> !DSPAM:10175,4ffa628b11850120912003! _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> 
> !DSPAM:10175,4ffa628b11850120912003!