<div dir="ltr"><br><div style>I'm sold. I often to do analysis on the projection object, so the scheme Nathan outlined in his second email works just fine for me. It makes a ton of sense to separate the functionality and avoid parameter clashes and redundant functionality. </div>
<div style><br></div><div style><br></div><div style>d.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 9, 2013 at 8:03 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Cameron, Dave and Nathan,<br>
<br>
I was actually the driving force behind removing the argument, and in<br>
fact, I'd like to be the driving force behind removing *most* of the<br>
kwargs that delve into a lot of stateful and "magic" object creation.<br>
(i.e., with the movie making, for instance.) I think it leads to a<br>
lot of leakiness -- we can't cover all possible use cases, but as we<br>
creep along, adding new things, we keep finding new areas that we want<br>
to cover. So the number of keyword arguments grows. But then, the<br>
number of potential conflicts between them grows, as does the<br>
duplication of code, and so on and so forth. I guess what I'm saying<br>
is, we have too many ways to do similar and identical things. And a<br>
lot of that can be traced back to mistakes I have made in the past.<br>
Much of the yt API was not designed, it was grown -- and watching<br>
other projects more closely over the last few years, I've come to<br>
really understand better how to work on design, and forethought, and<br>
trying to ensure a consistent experience.<br>
<br>
With the plot window, we tried to strip it down; they'd make a few<br>
well-meaning decisions about what can be done to make a plot, and if<br>
that wasn't good enough, it would throw up its hands and say, okay,<br>
you do it. Specifically, I think this applies when we think about the<br>
ways of creating objects that plots are built from.<br>
<br>
But ... Cameron, your comment about matplotlib made me think about<br>
this a bit more. I don't want to aspire to the style of API that<br>
Matplotlib has; in particular, I don't want to aim for the large<br>
number of kwargs, which I think tends to lead to some confusion at<br>
times. However, I was reminded of the talk at SciPy 2012 by the late<br>
John Hunter, entitled, "Matplotlib: Lessons from Middle Age." During<br>
the talk, I remember being struck by what a marvelous distillation of<br>
running a community project he had presented.<br>
<br>
Here is that talk: <a href="http://www.youtube.com/watch?v=e3lTby5RI54" target="_blank">http://www.youtube.com/watch?v=e3lTby5RI54</a> (highly<br>
recommended viewing)<br>
<br>
One of the things I wrote down (I dug out my notebook for this email)<br>
was "Solid API". I even circled it. Later on I wrote, "Get a<br>
familiar, stable, user-facing API right away." And when I saw that<br>
tonight, I realized I was in the wrong on this one. We should not be<br>
removing this option, not because it belongs there, but because it's<br>
something people rely upon. And we have a responsibility not to break<br>
things unless absolutely necessary -- and sometimes it is necessary.<br>
But an improvement in elegance is not necessity.<br>
<br>
So we can decide how one might deprecate something like this; perhaps<br>
in the 3.0 branch, when we will have other different types of<br>
upgrades, we can consider removing it. But I was wrong to encourage<br>
Nathan to remove it now. In return, I think that what we as code<br>
reviewers should be doing is carefully considering the design of APIs<br>
that become exposed and that get built on. Thanks for helping me<br>
remember this.<br>
<br>
-Matt<br>
<br>
PS On a personal note, shortly after his talk I was able to find John<br>
and sincerely thank him for his candid, thoughtful and earnest<br>
presentation. His talk really was the highlight of my trip to SciPy<br>
2012, and I am so very grateful I was able to tell him so.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Thu, May 9, 2013 at 5:33 PM, Cameron Hummels <<a href="mailto:chummels@gmail.com">chummels@gmail.com</a>> wrote:<br>
> I've used max_level coupled with annotate_grid (and it's own max_level) in<br>
> the past to highlight different structures in projections. I guess I don't<br>
> see why we're removing functionality here. You'd rather have all display<br>
> flags associated with the different plot functions? So in order to<br>
> replicate the functionality i describe above, this would mean creating a<br>
> cutting region with its own max_level on a given object for each level and<br>
> then piping each to projectionplot?<br>
><br>
> I guess I'm not entirely behind the goals you have set out, explicitly to<br>
> "remove rarely-used kwargs" from the plotting functions. Matplotlib has<br>
> about 10 bajillion kwargs associated with its functions that aren't always<br>
> used, but it's nice to have them around for when you do need them. I don't<br>
> see having a lot of them around as a hindrance, as long as you make the<br>
> default behavior what one would expect. Most users will never have to<br>
> fiddle with them, but they may come in handy in rare circumstances. If<br>
> having them around prevents normal users from spending a few hours trying to<br>
> make a workaround for something that once did exist, then I say leave them<br>
> in.<br>
><br>
> I'm -1 on removing this functionality from the plotting routines, but I'm<br>
> still open to hearing other opinions on the matter.<br>
><br>
><br>
> On Thu, May 9, 2013 at 5:07 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, May 9, 2013 at 5:05 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>><br>
>> wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > As part of the eternal journey that is making yt's plotting code as<br>
>> > awesome<br>
>> > as possible, we've endeavored to make the plotting code as flexible as<br>
>> > it<br>
>> > needs to be for quick use but simple enough that a use isn't overloaded<br>
>> > by<br>
>> > unnecessary or barely-used keyword arguments.<br>
>> ><br>
>> > Right now there is a pending PR to rework some of the plotting routines,<br>
>> > adding a couple of new features, and, per the subject of this e-mail,<br>
>> > removing the max_level keyword from ProjectionPlot.<br>
>> ><br>
>> > I could see how having max_level might be useful if projections are very<br>
>> > slow for a user's dataset. However, she should be able to get the exact<br>
>> > same result by explicitly constructing a projection data object and then<br>
>> > creating a plot for it using projection.to_pw(). I also think in<br>
>> > practice<br>
>> > max_level isn't used very often since projections are quite fast, even<br>
>> > on<br>
>> > large datasets.<br>
>><br>
>> I'm strongly in favor of keeping the ProjectionPlot, SlicePlot, etc,<br>
>> all focused on display-related items, rather than data-related items.<br>
>> I feel like they should be a good way to make sensible default objects<br>
>> and then detailed modifications of plots from them. That's why we<br>
>> have .to_pw(), right? :) But I would like to hear if anyone<br>
>> disagrees and thinks we need to keep max_level.<br>
>><br>
>> ><br>
>> > Am I incorrect in that assessment? Please let me know if you'd like to<br>
>> > keep<br>
>> > the max_level keyword around and I'll happily revert that part of the<br>
>> > pull<br>
>> > request.<br>
>> ><br>
>> > Thanks for your help,<br>
>> ><br>
>> > Nathan<br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>> ><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Cameron Hummels<br>
> Postdoctoral Researcher<br>
> Steward Observatory<br>
> University of Arizona<br>
> <a href="http://chummels.org" target="_blank">http://chummels.org</a><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Sent from my computer.
</div>