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

david collins antpuncher at gmail.com
Thu May 9 14:25:48 PDT 2013


I have used that max_level in the past, for both debugging and restricted
analysis (and hope to again soon, for the same reasons).  But if the same
functionality is available elsewhere, I don't have any stake in that
particular keyword in that particular function.


On Thu, May 9, 2013 at 3: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
>



-- 
Sent from my computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130509/f666a967/attachment.htm>


More information about the yt-dev mailing list