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@gmail.com> wrote:


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


On Wed, Dec 21, 2016 at 3:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:


On Wed, Dec 21, 2016 at 2:55 PM, Yi-Hao Chen <yihaochentw@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:


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')

    # 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.
 

Thanks!
Yi-Hao

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org