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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 on attaching the functions directly instead of via a dictionary, for all the reasons above. How often is a dict of callbacks useful? Is it common to add callbacks at runtime -- is that the reason for the dict of funcs? chris On Sunday, July 8, 2012, 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@berkeley.edu<javascript:_e({}, 'cvml', 'atmyers@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@ucolick.org<javascript:_e({}, 'cvml', 'goldbaum@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@lists.spacepope.org <javascript:_e({}, 'cvml', 'yt-dev@lists.spacepope.org');> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e({}, 'cvml', 'yt-dev@lists.spacepope.org');> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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-attrib... 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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4ffa628b11850120912003! _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
!DSPAM:10175,4ffa628b11850120912003!
participants (4)
-
Andrew Myers -
Casey W. Stark -
Christopher Moody -
Nathan Goldbaum