[yt-dev] Why does ProjectionPlot not take and pass **kwargs

[Nathan Goldbaum]

On Wed, Dec 21, 2016 at 4:31 PM, Yi-Hao Chen <yihaochentw at gmail.com> wrote:

>
>
> On Wed, Dec 21, 2016 at 3:54 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>> Another option might be to add something like matplotlib's setp command,
>> that allows you to efficiently (albeit cryptically) call a bunch of setters
>> all at once.
>>
>> -Nathan
>>
>> On Wed, Dec 21, 2016 at 3:53 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 21, 2016 at 3:37 PM, Yi-Hao Chen <yihaochentw at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 21, 2016 at 3:04 PM, Nathan Goldbaum <nathan12343 at gmail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 21, 2016 at 2:55 PM, Yi-Hao Chen <yihaochentw at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am wondering why ProjectionPlot (and others) do not take all the
>>>>>> keyword arguments and pass them to PWViewerMPL and PlotWindow. For example,
>>>>>> currently there is no way to set buff_size at the creation of a plot. One
>>>>>> has to call .set_buff_size after the plot was created.
>>>>>>
>>>>>> I am thinking about leaving only the arguments specific to
>>>>>> ProjectionPlot explicitly, and use **kwargs to pass all other arguments to
>>>>>> PlotWindow. But if there are reasons not to do this, please let me know.
>>>>>>
>>>>>
>>>>> This is on purpose, to reduce the API complexity. ProjectionPlot
>>>>> already has a huge number of keyword arguments, adding more will only make
>>>>> it harder to discover functionality.
>>>>>
>>>>
>>>> I see. That make sense.
>>>>
>>>>>
>>>>> I'd be much more interested in figuring out ways to make the setters
>>>>> more intuitive - possibly by exposing plot attributes as descriptors?
>>>>>
>>>>
>>>> I have no idea how to implement the descriptors...
>>>>
>>>
>>> Here's a nice article on descriptors that I've often referred to in the
>>> past:
>>>
>>> http://nbviewer.jupyter.org/urls/gist.github.com/ChrisBeaumo
>>> nt/5758381/raw/descriptor_writeup.ipynb
>>>
>>> The idea would be to expose the internal state for the plot objects via
>>> descriptors. This would make it possible to do, e.g.:
>>>
>>>     plot = yt.ProjectionPlot(ds, 2, 'density')
>>>
>>
> It seems that yt will already create an image with default buff_size =
> (800,800) here.  It will of course redraw the image again later when we set
> the attributes and save the plot, but wouldn't it be redundant to create
> the first image?
>

I think it's true that it does create an 800x800 image buffer here, but not
the actual matplotlib plot. Creating image buffers via the FRB interface is
quite fast - the slow bit is going through matplotlib and setting up,
decorating the plot, and drawing the plot.

In principle we could even delay creating the 800x800 buffer until we
actually need it when we call save()


>
>>>
>>     # both of these should work and be handled by the descriptor
>>>     plot.buff_size = (800, 1600)
>>>     plot.buff_size = np.array(800, 1600)
>>>
>>>     print(plot.buff_size)
>>>     plot.save()
>>>
>>> There are a number of plot attributes (some of them currently private)
>>> that we could handle (hopefully) more intuitively using this sort of API.
>>> The reason why I think it needs to happen (if it should happen) as part of
>>> a bigger refactoring is that we shouldn't leave the API partially converted
>>> to look like this, as that will be even more awkward to use.
>>>
>>
> I agree there should be a better way to access the plot attributes.
>
>>
>>>>>
>>>>
>>>>>> Thanks!
>>>>>> Yi-Hao
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20161221/f161d391/attachment.htm>