[yt-dev] Removing the max_level keyword argument from ProjectionPlot

[Nathan Goldbaum]

Hi Cameron,

Right now you can do:

pf = load(file)
plot = ProjectionPlot(pf, 0, 'Density', max_level=5)
plot.save()

If my proposed change goes through, you'll have to do:

pf = load(file)
proj = pf.h.projection(0, 'Density', max_level=5)
plot = proj.to_pw()
plot.save()

The idea here is to separate data selection into the projection object and keep the plotting routines focused on display and annotation.

Cheers,

-Nathan

On May 9, 2013, at 2:33 PM, Cameron Hummels <chummels at gmail.com> wrote:

> I've used max_level coupled with annotate_grid (and it's own max_level) in the past to highlight different structures in projections.  I guess I don't see why we're removing functionality here.  You'd rather have all display flags associated with the different plot functions?  So in order to replicate the functionality i describe above, this would mean creating a cutting region with its own max_level on a given object for each level and then piping each to projectionplot?
> 
> I guess I'm not entirely behind the goals you have set out, explicitly to "remove rarely-used kwargs" from the plotting functions.  Matplotlib has about 10 bajillion kwargs associated with its functions that aren't always used, but it's nice to have them around for when you do need them.  I don't see having a lot of them around as a hindrance, as long as you make the default behavior what one would expect.  Most users will never have to fiddle with them, but they may come in handy in rare circumstances.  If having them around prevents normal users from spending a few hours trying to make a workaround for something that once did exist, then I say leave them in.
> 
> I'm -1 on removing this functionality from the plotting routines, but I'm still open to hearing other opinions on the matter.
> 
> 
> On Thu, May 9, 2013 at 5:07 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> On Thu, May 9, 2013 at 5:05 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> > Hi all,
> >
> > As part of the eternal journey that is making yt's plotting code as awesome
> > as possible, we've endeavored to make the plotting code as flexible as it
> > needs to be for quick use but simple enough that a use isn't overloaded by
> > unnecessary or barely-used keyword arguments.
> >
> > Right now there is a pending PR to rework some of the plotting routines,
> > adding a couple of new features, and, per the subject of this e-mail,
> > removing the max_level keyword from ProjectionPlot.
> >
> > I could see how having max_level might be useful if projections are very
> > slow for a user's dataset.  However, she should be able to get the exact
> > same result by explicitly constructing a projection data object and then
> > creating a plot for it using projection.to_pw().  I also think in practice
> > max_level isn't used very often since projections are quite fast, even on
> > large datasets.
> 
> I'm strongly in favor of keeping the ProjectionPlot, SlicePlot, etc,
> all focused on display-related items, rather than data-related items.
> I feel like they should be a good way to make sensible default objects
> and then detailed modifications of plots from them.  That's why we
> have .to_pw(), right?  :)  But I would like to hear if anyone
> disagrees and thinks we need to keep max_level.
> 
> >
> > Am I incorrect in that assessment?  Please let me know if you'd like to keep
> > the max_level keyword around and I'll happily revert that part of the pull
> > request.
> >
> > Thanks for your help,
> >
> > Nathan
> >
> > _______________________________________________
> > 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
> 
> 
> 
> -- 
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130509/062f3cdc/attachment.htm>