From quantum.analyst at gmail.com Thu Aug 13 21:56:47 2020 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Thu, 13 Aug 2020 21:56:47 -0400 Subject: [Matplotlib-users] [ANN] Matplotlib 3.3.1 Message-ID: Hi all, We are pleased to announce the release of 3.3.1. This is the first bug fix release of the 3.3.x series. Pre-built wheels are available for most major platforms, and can be installed using `pip install matplotlib==3.3.1`. Other packages may also be available already; please check with your preferred source. We are experimenting with a different method of producing wheels. Please notify us if you run into any issues with them. The 3.3.1 release represents the work of 17 authors over 73 pull requests, and we thank them for their contributions. This release contains several critical bug-fixes: * fix docstring import issues when running Python with optimization * fix |hist| with categorical data, such as with Pandas * fix install on BSD systems * fix nbagg compatibility with Chrome 84+ * fix ordering of scatter marker size in 3D plots * fix performance regression when plotting |Path|s * fix reading from URL in |imread| * fix several regressions with new date epoch handling * fix some bad constrained and tight layout interactions with colorbars * fix use of customized toolbars in TkAgg and WXAgg backends For further details, please see the What's new in Matplotlib 3.3.1 page: https://matplotlib.org/3.3.1/users/whats_new.html and the milestone on GitHub: https://github.com/matplotlib/matplotlib/milestone/56?closed=1 This release is signed by my GPG key. The fingerprint is: 23CA B59E 3332 F94D 26BE F037 8D86 E7FA E5EB 0C10 and it is also used to sign this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From aathan_matplotlib at memeplex.com Sat Aug 15 16:24:58 2020 From: aathan_matplotlib at memeplex.com (Andrew Athan) Date: Sat, 15 Aug 2020 13:24:58 -0700 Subject: [Matplotlib-users] Adding artists without changing the underlying Axes etc. Message-ID: I have implemented speedups based on the copy_from_bbox() and restore_region() APIs (i.e., blit APIs) in conjunction with an Agg canvas (my destination is actually a file, not screen). I create a bar() plot, then grab the plot with copy_from_bbox(), then I create Line2D() artists and add them using ax.add_line(). Following this, I remove the artists, restore_region() and wash, rinse, repeat(). I'm finding that the process can lead to creep in data to screen transforms, which I guess must be due to bounding box changes when I add lines that may exceed the bbox. That's my theory. Is there a mechanism or recommended methodology to tell artists (and/or the axes they are being added to) not to recalculate anything, so that the underlying plot remains unchanged by the add()? A. From ram at rachum.com Sun Aug 23 13:39:40 2020 From: ram at rachum.com (Ram Rachum) Date: Sun, 23 Aug 2020 20:39:40 +0300 Subject: [Matplotlib-users] Declarative interface to matplotlib Message-ID: Hi everyone, I'd like to ask you a general question, as someone who isn't very experienced with matplotlib. I noticed that matplotlib is very imperative, in contrast to declarative. For example, I wanted to show an `imshow` plot with a colorbar, so I needed to first create the plot, then run `plt.colorbar()`, then show the plot. In more complicated plots, you could be doing 10+ actions one after another to create a plot. I would find a declarative interface to be much more elegant, i.e. one call to create the plot and lots of keyword arguments, some of them nested, to specify all the options. Of course, matplotlib being a very mature project, the current interface must be maintained forever. But, do you know of any such declarative interface to matplotlib? Either as part of the library, or a separate library that uses matplotlib? If such a thing doesn't exist, what would you think about adding one? Thanks, Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmay31 at gmail.com Sun Aug 23 15:30:50 2020 From: rmay31 at gmail.com (Ryan May) Date: Sun, 23 Aug 2020 13:30:50 -0600 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: Hi, The MetPy project has worked on a declarative, matplotlib-based plotting interface: https://unidata.github.io/MetPy/latest/examples/index.html#plotting https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html https://unidata.github.io/python-training/gallery/declarative_500_hpa/ This focuses, though, on domain-specific applications in meteorology and atmospheric science, leveraging the traitlets library. The interface was also designed to facilitate transition away from a legacy, declarative-like plotting tool. Not claiming by any means we have the interface perfect. We spent a lot of time trying to come up with new names for Figure and Axes in this interface since we did not want to collide with matplotlib's own classes. Honestly, the basic interface is pretty trivial to create (at least using traitlets). The challenge is to handle state update and invalidation properly when trying to support interactive use cases (especially when all of the classes are thin wrappers around matplotlib state). Ryan On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: > Hi everyone, > > I'd like to ask you a general question, as someone who isn't very > experienced with matplotlib. > > I noticed that matplotlib is very imperative, in contrast to declarative. > For example, I wanted to show an `imshow` plot with a colorbar, so I needed > to first create the plot, then run `plt.colorbar()`, then show the plot. In > more complicated plots, you could be doing 10+ actions one after another to > create a plot. > > I would find a declarative interface to be much more elegant, i.e. one > call to create the plot and lots of keyword arguments, some of them nested, > to specify all the options. Of course, matplotlib being a very mature > project, the current interface must be maintained forever. But, do you know > of any such declarative interface to matplotlib? Either as part of the > library, or a separate library that uses matplotlib? > > If such a thing doesn't exist, what would you think about adding one? > > > Thanks, > Ram. > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at python.org > https://mail.python.org/mailman/listinfo/matplotlib-users > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram at rachum.com Sun Aug 23 15:55:00 2020 From: ram at rachum.com (Ram Rachum) Date: Sun, 23 Aug 2020 22:55:00 +0300 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: Thanks Ryan, that's interesting. On Sun, Aug 23, 2020 at 10:31 PM Ryan May wrote: > Hi, > > The MetPy project has worked on a declarative, matplotlib-based plotting > interface: > > https://unidata.github.io/MetPy/latest/examples/index.html#plotting > https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html > https://unidata.github.io/python-training/gallery/declarative_500_hpa/ > > This focuses, though, on domain-specific applications in meteorology and > atmospheric science, leveraging the traitlets library. The interface was > also designed to facilitate transition away from a legacy, declarative-like > plotting tool. > > Not claiming by any means we have the interface perfect. We spent a lot of > time trying to come up with new names for Figure and Axes in this interface > since we did not want to collide with matplotlib's own classes. Honestly, > the basic interface is pretty trivial to create (at least using traitlets). > The challenge is to handle state update and invalidation properly when > trying to support interactive use cases (especially when all of the classes > are thin wrappers around matplotlib state). > > Ryan > > On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: > >> Hi everyone, >> >> I'd like to ask you a general question, as someone who isn't very >> experienced with matplotlib. >> >> I noticed that matplotlib is very imperative, in contrast to declarative. >> For example, I wanted to show an `imshow` plot with a colorbar, so I needed >> to first create the plot, then run `plt.colorbar()`, then show the plot. In >> more complicated plots, you could be doing 10+ actions one after another to >> create a plot. >> >> I would find a declarative interface to be much more elegant, i.e. one >> call to create the plot and lots of keyword arguments, some of them nested, >> to specify all the options. Of course, matplotlib being a very mature >> project, the current interface must be maintained forever. But, do you know >> of any such declarative interface to matplotlib? Either as part of the >> library, or a separate library that uses matplotlib? >> >> If such a thing doesn't exist, what would you think about adding one? >> >> >> Thanks, >> Ram. >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-users >> > > > -- > Ryan May > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sun Aug 23 21:30:11 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 23 Aug 2020 21:30:11 -0400 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: I think declarative APIs can be very terse if they are well tuned for a given domain, however as you expand them to cover the general case it is not clear to me that you will be able to preserve that terseness. Put another way, there is some inherent complexity in making a plot. An imperative API can rely on the host language (Python) to handle some of that complexity whereas a declarative API must absorb all of the complexity. Either it will grow to be as complex as a programming language or it will have to restrict its users to the vocabulary that the original developers imagined. On the other hand, if the declarative API matches what you need (it makes all the right assumptions for your task and data) it can be great! If you are finding yourself doing the same 10 things every time, I suggest putting that into a function and eventually growing that into a library / declarative API that is tuned to your data / domain / use. Tom On Sun, Aug 23, 2020 at 3:59 PM Ram Rachum wrote: > Thanks Ryan, that's interesting. > > On Sun, Aug 23, 2020 at 10:31 PM Ryan May wrote: > >> Hi, >> >> The MetPy project has worked on a declarative, matplotlib-based plotting >> interface: >> >> https://unidata.github.io/MetPy/latest/examples/index.html#plotting >> https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html >> https://unidata.github.io/python-training/gallery/declarative_500_hpa/ >> >> This focuses, though, on domain-specific applications in meteorology and >> atmospheric science, leveraging the traitlets library. The interface was >> also designed to facilitate transition away from a legacy, declarative-like >> plotting tool. >> >> Not claiming by any means we have the interface perfect. We spent a lot >> of time trying to come up with new names for Figure and Axes in this >> interface since we did not want to collide with matplotlib's own classes. >> Honestly, the basic interface is pretty trivial to create (at least using >> traitlets). The challenge is to handle state update and invalidation >> properly when trying to support interactive use cases (especially when all >> of the classes are thin wrappers around matplotlib state). >> >> Ryan >> >> On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: >> >>> Hi everyone, >>> >>> I'd like to ask you a general question, as someone who isn't very >>> experienced with matplotlib. >>> >>> I noticed that matplotlib is very imperative, in contrast to >>> declarative. For example, I wanted to show an `imshow` plot with a >>> colorbar, so I needed to first create the plot, then run `plt.colorbar()`, >>> then show the plot. In more complicated plots, you could be doing 10+ >>> actions one after another to create a plot. >>> >>> I would find a declarative interface to be much more elegant, i.e. one >>> call to create the plot and lots of keyword arguments, some of them nested, >>> to specify all the options. Of course, matplotlib being a very mature >>> project, the current interface must be maintained forever. But, do you know >>> of any such declarative interface to matplotlib? Either as part of the >>> library, or a separate library that uses matplotlib? >>> >>> If such a thing doesn't exist, what would you think about adding one? >>> >>> >>> Thanks, >>> Ram. >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Matplotlib-users at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-users >>> >> >> >> -- >> Ryan May >> >> _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at python.org > https://mail.python.org/mailman/listinfo/matplotlib-users > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From story645 at gmail.com Mon Aug 24 00:13:23 2020 From: story645 at gmail.com (Hannah) Date: Mon, 24 Aug 2020 00:13:23 -0400 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: If you want an out of the box decelerative API, plotnine is a ggplot API inspired wrapper over Matplotlib. https://plotnine.readthedocs.io/en/stable/ It also kind of stalled out, but their was some work on an mpl-altair backend to Altair so that you could use the Vegalite grammar and we'd support that project getting picked up again https://github.com/matplotlib/mpl-altair Like Tom said though, it may be cleaner to start w/ your usecase and build a declarative wrapper around that. On Sun, Aug 23, 2020, 1:39 PM Ram Rachum wrote: > Hi everyone, > > I'd like to ask you a general question, as someone who isn't very > experienced with matplotlib. > > I noticed that matplotlib is very imperative, in contrast to declarative. > For example, I wanted to show an `imshow` plot with a colorbar, so I needed > to first create the plot, then run `plt.colorbar()`, then show the plot. In > more complicated plots, you could be doing 10+ actions one after another to > create a plot. > > I would find a declarative interface to be much more elegant, i.e. one > call to create the plot and lots of keyword arguments, some of them nested, > to specify all the options. Of course, matplotlib being a very mature > project, the current interface must be maintained forever. But, do you know > of any such declarative interface to matplotlib? Either as part of the > library, or a separate library that uses matplotlib? > > If such a thing doesn't exist, what would you think about adding one? > > > Thanks, > Ram. > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at python.org > https://mail.python.org/mailman/listinfo/matplotlib-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon Aug 24 00:14:41 2020 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 24 Aug 2020 00:14:41 -0400 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: Isn't Altair trying to be a declarative interface to matplotlib? Also, I could have sworn someone made a ggplot clone using matplotlib as a base? Ben Root On Sun, Aug 23, 2020 at 9:30 PM Thomas Caswell wrote: > I think declarative APIs can be very terse if they are well tuned for a > given domain, however as you expand them to cover the general case it is > not clear to me that you will be able to preserve that terseness. > > Put another way, there is some inherent complexity in making a plot. An > imperative API can rely on the host language (Python) to handle some of > that complexity whereas a declarative API must absorb all of the > complexity. Either it will grow to be as complex as a programming language > or it will have to restrict its users to the vocabulary that the original > developers imagined. On the other hand, if the declarative API matches > what you need (it makes all the right assumptions for your task and data) > it can be great! > > If you are finding yourself doing the same 10 things every time, I suggest > putting that into a function and eventually growing that into a library / > declarative API that is tuned to your data / domain / use. > > Tom > > On Sun, Aug 23, 2020 at 3:59 PM Ram Rachum wrote: > >> Thanks Ryan, that's interesting. >> >> On Sun, Aug 23, 2020 at 10:31 PM Ryan May wrote: >> >>> Hi, >>> >>> The MetPy project has worked on a declarative, matplotlib-based plotting >>> interface: >>> >>> https://unidata.github.io/MetPy/latest/examples/index.html#plotting >>> https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html >>> https://unidata.github.io/python-training/gallery/declarative_500_hpa/ >>> >>> This focuses, though, on domain-specific applications in meteorology and >>> atmospheric science, leveraging the traitlets library. The interface was >>> also designed to facilitate transition away from a legacy, declarative-like >>> plotting tool. >>> >>> Not claiming by any means we have the interface perfect. We spent a lot >>> of time trying to come up with new names for Figure and Axes in this >>> interface since we did not want to collide with matplotlib's own classes. >>> Honestly, the basic interface is pretty trivial to create (at least using >>> traitlets). The challenge is to handle state update and invalidation >>> properly when trying to support interactive use cases (especially when all >>> of the classes are thin wrappers around matplotlib state). >>> >>> Ryan >>> >>> On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: >>> >>>> Hi everyone, >>>> >>>> I'd like to ask you a general question, as someone who isn't very >>>> experienced with matplotlib. >>>> >>>> I noticed that matplotlib is very imperative, in contrast to >>>> declarative. For example, I wanted to show an `imshow` plot with a >>>> colorbar, so I needed to first create the plot, then run `plt.colorbar()`, >>>> then show the plot. In more complicated plots, you could be doing 10+ >>>> actions one after another to create a plot. >>>> >>>> I would find a declarative interface to be much more elegant, i.e. one >>>> call to create the plot and lots of keyword arguments, some of them nested, >>>> to specify all the options. Of course, matplotlib being a very mature >>>> project, the current interface must be maintained forever. But, do you know >>>> of any such declarative interface to matplotlib? Either as part of the >>>> library, or a separate library that uses matplotlib? >>>> >>>> If such a thing doesn't exist, what would you think about adding one? >>>> >>>> >>>> Thanks, >>>> Ram. >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Matplotlib-users at python.org >>>> https://mail.python.org/mailman/listinfo/matplotlib-users >>>> >>> >>> >>> -- >>> Ryan May >>> >>> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-users >> > > > -- > Thomas Caswell > tcaswell at gmail.com > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at python.org > https://mail.python.org/mailman/listinfo/matplotlib-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon Aug 24 00:15:32 2020 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 24 Aug 2020 00:15:32 -0400 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: jinx! On Mon, Aug 24, 2020 at 12:14 AM Benjamin Root wrote: > Isn't Altair trying to be a declarative interface to matplotlib? > > Also, I could have sworn someone made a ggplot clone using matplotlib as a > base? > > Ben Root > > > On Sun, Aug 23, 2020 at 9:30 PM Thomas Caswell wrote: > >> I think declarative APIs can be very terse if they are well tuned for a >> given domain, however as you expand them to cover the general case it is >> not clear to me that you will be able to preserve that terseness. >> >> Put another way, there is some inherent complexity in making a plot. An >> imperative API can rely on the host language (Python) to handle some of >> that complexity whereas a declarative API must absorb all of the >> complexity. Either it will grow to be as complex as a programming language >> or it will have to restrict its users to the vocabulary that the original >> developers imagined. On the other hand, if the declarative API matches >> what you need (it makes all the right assumptions for your task and data) >> it can be great! >> >> If you are finding yourself doing the same 10 things every time, I >> suggest putting that into a function and eventually growing that into a >> library / declarative API that is tuned to your data / domain / use. >> >> Tom >> >> On Sun, Aug 23, 2020 at 3:59 PM Ram Rachum wrote: >> >>> Thanks Ryan, that's interesting. >>> >>> On Sun, Aug 23, 2020 at 10:31 PM Ryan May wrote: >>> >>>> Hi, >>>> >>>> The MetPy project has worked on a declarative, matplotlib-based >>>> plotting interface: >>>> >>>> https://unidata.github.io/MetPy/latest/examples/index.html#plotting >>>> https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html >>>> >>>> https://unidata.github.io/python-training/gallery/declarative_500_hpa/ >>>> >>>> This focuses, though, on domain-specific applications in meteorology >>>> and atmospheric science, leveraging the traitlets library. The interface >>>> was also designed to facilitate transition away from a legacy, >>>> declarative-like plotting tool. >>>> >>>> Not claiming by any means we have the interface perfect. We spent a lot >>>> of time trying to come up with new names for Figure and Axes in this >>>> interface since we did not want to collide with matplotlib's own classes. >>>> Honestly, the basic interface is pretty trivial to create (at least using >>>> traitlets). The challenge is to handle state update and invalidation >>>> properly when trying to support interactive use cases (especially when all >>>> of the classes are thin wrappers around matplotlib state). >>>> >>>> Ryan >>>> >>>> On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I'd like to ask you a general question, as someone who isn't very >>>>> experienced with matplotlib. >>>>> >>>>> I noticed that matplotlib is very imperative, in contrast to >>>>> declarative. For example, I wanted to show an `imshow` plot with a >>>>> colorbar, so I needed to first create the plot, then run `plt.colorbar()`, >>>>> then show the plot. In more complicated plots, you could be doing 10+ >>>>> actions one after another to create a plot. >>>>> >>>>> I would find a declarative interface to be much more elegant, i.e. one >>>>> call to create the plot and lots of keyword arguments, some of them nested, >>>>> to specify all the options. Of course, matplotlib being a very mature >>>>> project, the current interface must be maintained forever. But, do you know >>>>> of any such declarative interface to matplotlib? Either as part of the >>>>> library, or a separate library that uses matplotlib? >>>>> >>>>> If such a thing doesn't exist, what would you think about adding one? >>>>> >>>>> >>>>> Thanks, >>>>> Ram. >>>>> _______________________________________________ >>>>> Matplotlib-users mailing list >>>>> Matplotlib-users at python.org >>>>> https://mail.python.org/mailman/listinfo/matplotlib-users >>>>> >>>> >>>> >>>> -- >>>> Ryan May >>>> >>>> _______________________________________________ >>> Matplotlib-users mailing list >>> Matplotlib-users at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-users >>> >> >> >> -- >> Thomas Caswell >> tcaswell at gmail.com >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram at rachum.com Mon Aug 24 03:46:50 2020 From: ram at rachum.com (Ram Rachum) Date: Mon, 24 Aug 2020 10:46:50 +0300 Subject: [Matplotlib-users] Declarative interface to matplotlib In-Reply-To: References: Message-ID: Thanks for the answers guys! On Mon, Aug 24, 2020 at 7:16 AM Benjamin Root wrote: > jinx! > > On Mon, Aug 24, 2020 at 12:14 AM Benjamin Root > wrote: > >> Isn't Altair trying to be a declarative interface to matplotlib? >> >> Also, I could have sworn someone made a ggplot clone using matplotlib as >> a base? >> >> Ben Root >> >> >> On Sun, Aug 23, 2020 at 9:30 PM Thomas Caswell >> wrote: >> >>> I think declarative APIs can be very terse if they are well tuned for a >>> given domain, however as you expand them to cover the general case it is >>> not clear to me that you will be able to preserve that terseness. >>> >>> Put another way, there is some inherent complexity in making a plot. An >>> imperative API can rely on the host language (Python) to handle some of >>> that complexity whereas a declarative API must absorb all of the >>> complexity. Either it will grow to be as complex as a programming language >>> or it will have to restrict its users to the vocabulary that the original >>> developers imagined. On the other hand, if the declarative API matches >>> what you need (it makes all the right assumptions for your task and data) >>> it can be great! >>> >>> If you are finding yourself doing the same 10 things every time, I >>> suggest putting that into a function and eventually growing that into a >>> library / declarative API that is tuned to your data / domain / use. >>> >>> Tom >>> >>> On Sun, Aug 23, 2020 at 3:59 PM Ram Rachum wrote: >>> >>>> Thanks Ryan, that's interesting. >>>> >>>> On Sun, Aug 23, 2020 at 10:31 PM Ryan May wrote: >>>> >>>>> Hi, >>>>> >>>>> The MetPy project has worked on a declarative, matplotlib-based >>>>> plotting interface: >>>>> >>>>> https://unidata.github.io/MetPy/latest/examples/index.html#plotting >>>>> >>>>> https://unidata.github.io/MetPy/latest/api/generated/metpy.plots.html >>>>> >>>>> https://unidata.github.io/python-training/gallery/declarative_500_hpa/ >>>>> >>>>> This focuses, though, on domain-specific applications in meteorology >>>>> and atmospheric science, leveraging the traitlets library. The interface >>>>> was also designed to facilitate transition away from a legacy, >>>>> declarative-like plotting tool. >>>>> >>>>> Not claiming by any means we have the interface perfect. We spent a >>>>> lot of time trying to come up with new names for Figure and Axes in this >>>>> interface since we did not want to collide with matplotlib's own classes. >>>>> Honestly, the basic interface is pretty trivial to create (at least using >>>>> traitlets). The challenge is to handle state update and invalidation >>>>> properly when trying to support interactive use cases (especially when all >>>>> of the classes are thin wrappers around matplotlib state). >>>>> >>>>> Ryan >>>>> >>>>> On Sun, Aug 23, 2020 at 11:39 AM Ram Rachum wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'd like to ask you a general question, as someone who isn't very >>>>>> experienced with matplotlib. >>>>>> >>>>>> I noticed that matplotlib is very imperative, in contrast to >>>>>> declarative. For example, I wanted to show an `imshow` plot with a >>>>>> colorbar, so I needed to first create the plot, then run `plt.colorbar()`, >>>>>> then show the plot. In more complicated plots, you could be doing 10+ >>>>>> actions one after another to create a plot. >>>>>> >>>>>> I would find a declarative interface to be much more elegant, i.e. >>>>>> one call to create the plot and lots of keyword arguments, some of them >>>>>> nested, to specify all the options. Of course, matplotlib being a very >>>>>> mature project, the current interface must be maintained forever. But, do >>>>>> you know of any such declarative interface to matplotlib? Either as part of >>>>>> the library, or a separate library that uses matplotlib? >>>>>> >>>>>> If such a thing doesn't exist, what would you think about adding one? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Ram. >>>>>> _______________________________________________ >>>>>> Matplotlib-users mailing list >>>>>> Matplotlib-users at python.org >>>>>> https://mail.python.org/mailman/listinfo/matplotlib-users >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ryan May >>>>> >>>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Matplotlib-users at python.org >>>> https://mail.python.org/mailman/listinfo/matplotlib-users >>>> >>> >>> >>> -- >>> Thomas Caswell >>> tcaswell at gmail.com >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Matplotlib-users at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: