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

[Cameron Hummels]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130509/ce724078/attachment.htm>