On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root <ben.r...@ou.edu> wrote:
> It doesn't feel weird. It feels generalized.
>
or both ;-)
It is the same way to add any number of plots, regardless if it is just
> one, or twenty. If you don't want to do it that way, you can just simply do:
>
> fig = plt.figure()
> ax = fig.gca() # "get current axes" automatically creates an axes if one
>
rally ugly -- the whole point here is to get away from the concept of a
"current" anything -- I'm actually surprised that that's a figure method at
all...
It does:
http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot
> This is *the* function that does axes creation for a figure, whether it is
> one, or many.
>
> subplots() is a recent addition.
>
And a nice one -- I've been wanting that for years! (and I
first discovered it in your tutorial, Ben!) The trick has always been that
plot() actually creates (If not re-using) three objects you might want to
work with: figure, axes, and line objects, so an oo interface that lets you
do that with one call is tricky -- I think this is a nice compromise.
We are in the process of updating our documentation. But add_subplot() is
> not going away because it works just fine, and it is very familiar to users
> of Matlab and Octave.
>
I've lost track a bit if there is support for a new OO-only API
(namespace), in which case, maybe some of this could be cleaned up as well.
I'd kind of like to see a fig.subplots() that has the same API as
plt.subplots(), for symmetry's sake, and because add_subplot() has a kind
of crufty API. Except it wouldn't return the figure instance (though it
could).
-Chris
>
>
>> In principle I think the current API violates the "There should be one--
>> and preferably only one --obvious way to do it" rule here, and elsewhere
>> :-)
>>
>>
> I feel the way forward should be to create a cleaner API and map the
>> current one through a compatibility layer to that.
>>
>>
> This has already been done. We have the GridSpec API that everything else
> maps to, for compatibility. But most people still like add_subplot() and
> subplots() for some odd reason... I think the primary issue is one of
> documentation, and we are currently in the process of upgrading that. We
> always welcome contributions to that effort!
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
