From rob.a.mcdonald at gmail.com Mon Apr 1 10:27:34 2019 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Mon, 1 Apr 2019 09:27:34 -0500 Subject: [Matplotlib-devel] What is draw_path's transform's destination? In-Reply-To: References: Message-ID: For the record, I was able to resolve this issue as well. This SO answer references a response to a GitHub issue that gives the critical clue -- to_polygons has a hard-coded resolution of 1 because it expects to work in pixel space. So, if I transform the Path before evaluating it, I get acceptable results. Thanks, Rob On Sun, Mar 31, 2019 at 12:30 AM Rob McDonald wrote: > On Sat, Mar 30, 2019 at 11:51 PM Rob McDonald > wrote: > >> Unfortunately, naively passing path_effects=[HatchedStroke()] to a >> plt.contour() call doesn't 'just work'. Is there a way to tell contour >> lines to be drawn with a different path effect? >> >> > OK -- so I made some progress on this... > > cp = plt.contour(x, y, z, colors=('k',), ) > plt.setp(cp.collections, path_effects=[HatchedStroke()]) > > By and large works. However, some of the hatches appear 'off' the lines. > I believe this is because some of the contour Path's might be generated as > Bezier curves (not simple polylines). I need to interpolate along the path > to generate hatches, but I don't have a full renderer -- and > Path.interpolate doesn't do curves. I currently do the following to get to > polylines > > newpath = tpath.cleaned() > polys = newpath.to_polygons(closed_only=False) > > Which generally works, but the default settings (deep inside agg from what > I can tell (agg_curves.cpp etc.)) produce very coarse approximations that > are rather unsatisfying. > > Is there a better way to get a polyline from an arbitrary Path (that may > include Bezier curves)? Someone has to have implemented a compound path > evaluation routine... > > Alternately, is there a way to force contour to generate straight-line > segments -- forcing the user to bump up the grid resolution if they want > smooth curves? Actually, that doesn't work. I currently have an example > with very fine resolution -- it appears that something in the Contour Path > hierarchy is being clever and replacing the polyline segments with a smooth > Bezier curve. Possibly via a simplify call -- if there isn't a way to > evaluate the true Path in draw_path, then perhaps there is a way to turn > off the simplify step contour is doing... > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From millman at berkeley.edu Thu Apr 4 20:50:08 2019 From: millman at berkeley.edu (Jarrod Millman) Date: Thu, 4 Apr 2019 17:50:08 -0700 Subject: [Matplotlib-devel] NetworkX 2.3rc3 released (Python 3 only) Message-ID: I am happy to announce the third **release candidate** for NetworkX 2.3! NetworkX is a Python package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks. This release supports Python 3.5-3.7 (i.e., this is our first **Python 3 only** release). Please try out the pre-release and let us know about any problems you find. If no major issues arise, we will release 2.3 final next week. Please see the draft of the 2.3 release announcement: https://networkx.github.io/documentation/latest/release/release_dev.html Since this is a pre-release, pip won't automatically install it. So $ pip install networkx still installs networkx-2.2. But $ pip install --pre networkx will install networkx-2.3rc3. If you already have networkx installed then you need to do $ pip install --pre --upgrade networkx For more information, please visit our `website `_ and our `gallery of examples `_. Please send comments and questions to the `networkx-discuss mailing list `_. Best regards, Jarrod From efiring at hawaii.edu Tue Apr 16 03:19:05 2019 From: efiring at hawaii.edu (Eric Firing) Date: Mon, 15 Apr 2019 21:19:05 -1000 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> Message-ID: <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> In today's weekly meeting, with Hannah, Thomas, and myself, we discussed https://github.com/matplotlib/matplotlib/issues/8519, which points to the long-standing problem that matplotlib relies on garbage collection to release memory after a figure is closed. With some work-flows the automatic collection doesn't happen often enough and the user must explicitly trigger it. It would be better if pyplot cleaned up after itself, breaking reference cycles when a figure is closed. I think it is time to make this change, so I marked the issue "Release-critical". I am hoping we can get this done as a high-priority task, *early* in the 3.2 cycle. The central point is that closing a figure should clear it, and clearing it should recursively walk through the children, breaking connections and reference cycles all the way down. One possibility would be to modify or replace the figure object such that any attempt to operate on the figure after closing would fail by raising an informative exception. Question: should closing the gui window also close the figure? No, because that would prevent the user from calling savefig on it. This would interfere with a reasonable use-case, in which plt.show is used in blocking mode, the window is closed, and the figure is saved via savefig. Problem: if closing the gui window doesn't close the figure, how can it ever be closed? This leads to the suggestion that the pyplot state manager keep a list of "latent figures" which are no longer displayed in a gui window but have not been closed. They could then be explicitly closed by "plt.close('all')". This also opens the possibility for an API allowing one to re-display a figure after closing its gui window. For example, one might do a calculation, show it in a figure in a blocking window with "plt.show", close the window, do additional calculations, add them to the same figure, and bring the figure back in a new gui window. This might be done in a loop, incrementing the contents of the figure. See also: https://github.com/matplotlib/matplotlib/issues/6793 https://github.com/matplotlib/matplotlib/issues/6982 Eric From jklymak at uvic.ca Tue Apr 16 10:50:21 2019 From: jklymak at uvic.ca (Jody Klymak) Date: Tue, 16 Apr 2019 07:50:21 -0700 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> Message-ID: I think if it makes our lives easier the paradigm that a closed window means the figure is closed programmatically is pretty straightforward and standard across GUI interfaces. If folks need a workflow where they access the figure while it?s open they can turn off blocking. I vote we keep it simple and predictable rather than tie ourselves in knots with complicated ways of keeping track of what we think the user may want to do. Cheers. Jody Sent from my iPhone > On Apr 16, 2019, at 12:19 AM, Eric Firing wrote: > > > In today's weekly meeting, with Hannah, Thomas, and myself, we discussed https://github.com/matplotlib/matplotlib/issues/8519, which points to the long-standing problem that matplotlib relies on garbage collection to release memory after a figure is closed. With some work-flows the automatic collection doesn't happen often enough and the user must explicitly trigger it. It would be better if pyplot cleaned up after itself, breaking reference cycles when a figure is closed. I think it is time to make this change, so I marked the issue "Release-critical". I am hoping we can get this done as a high-priority task, *early* in the 3.2 cycle. > > The central point is that closing a figure should clear it, and clearing it should recursively walk through the children, breaking connections and reference cycles all the way down. One possibility would be to modify or replace the figure object such that any attempt to operate on the figure after closing would fail by raising an informative exception. > > Question: should closing the gui window also close the figure? No, because that would prevent the user from calling savefig on it. This would interfere with a reasonable use-case, in which plt.show is used in blocking mode, the window is closed, and the figure is saved via savefig. Problem: if closing the gui window doesn't close the figure, how can it ever be closed? > > This leads to the suggestion that the pyplot state manager keep a list of "latent figures" which are no longer displayed in a gui window but have not been closed. They could then be explicitly closed by "plt.close('all')". This also opens the possibility for an API allowing one to re-display a figure after closing its gui window. For example, one might do a calculation, show it in a figure in a blocking window with "plt.show", close the window, do additional calculations, add them to the same figure, and bring the figure back in a new gui window. This might be done in a loop, incrementing the contents of the figure. > > See also: > https://github.com/matplotlib/matplotlib/issues/6793 > https://github.com/matplotlib/matplotlib/issues/6982 > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From antony.lee at institutoptique.fr Tue Apr 16 11:54:29 2019 From: antony.lee at institutoptique.fr (Antony Lee) Date: Tue, 16 Apr 2019 17:54:29 +0200 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> Message-ID: Hi, It's actually not clear to me how GUI-closing and really closing are related (unless we decided that GUI closing means teardown, but I don't think we *need* that), and what the "latent figures" concept is supposed to achieve. Doesn't this approximately come down to 1) when calling plt.close(fig), do fig.clf() -> ax.cla() 2) in ax.cla(), before doing ax.lines = [], first do for line in ax.lines: line.remove()? (and similarly for other artists) Also, note that if one just wants to dump figures to your hard drive in a loop, I would strongly suggest not bothering with pyplot as all and just do "fig = matplotlib.figure.Figure(); ax = fig.subplots(); etc." The main issue with this approach is that it's a bit awkward to pop up a figure if one decides, after all, that they want to interactively play with it; a possibility would be to allow pyplot to "adopt" figures in a post-hoc manner via plt.show([fig1, fig2, ...]) ( https://github.com/matplotlib/matplotlib/pull/13590#issuecomment-469497636). Antony On Tue, Apr 16, 2019 at 5:41 PM Jody Klymak wrote: > I think if it makes our lives easier the paradigm that a closed window > means the figure is closed programmatically is pretty straightforward and > standard across GUI interfaces. If folks need a workflow where they access > the figure while it?s open they can turn off blocking. I vote we keep it > simple and predictable rather than tie ourselves in knots with complicated > ways of keeping track of what we think the user may want to do. > > Cheers. Jody > > Sent from my iPhone > > > On Apr 16, 2019, at 12:19 AM, Eric Firing wrote: > > > > > > In today's weekly meeting, with Hannah, Thomas, and myself, we discussed > https://github.com/matplotlib/matplotlib/issues/8519, which points to the > long-standing problem that matplotlib relies on garbage collection to > release memory after a figure is closed. With some work-flows the > automatic collection doesn't happen often enough and the user must > explicitly trigger it. It would be better if pyplot cleaned up after > itself, breaking reference cycles when a figure is closed. I think it is > time to make this change, so I marked the issue "Release-critical". I am > hoping we can get this done as a high-priority task, *early* in the 3.2 > cycle. > > > > The central point is that closing a figure should clear it, and clearing > it should recursively walk through the children, breaking connections and > reference cycles all the way down. One possibility would be to modify or > replace the figure object such that any attempt to operate on the figure > after closing would fail by raising an informative exception. > > > > Question: should closing the gui window also close the figure? No, > because that would prevent the user from calling savefig on it. This would > interfere with a reasonable use-case, in which plt.show is used in blocking > mode, the window is closed, and the figure is saved via savefig. Problem: > if closing the gui window doesn't close the figure, how can it ever be > closed? > > > > This leads to the suggestion that the pyplot state manager keep a list > of "latent figures" which are no longer displayed in a gui window but have > not been closed. They could then be explicitly closed by > "plt.close('all')". This also opens the possibility for an API allowing > one to re-display a figure after closing its gui window. For example, one > might do a calculation, show it in a figure in a blocking window with > "plt.show", close the window, do additional calculations, add them to the > same figure, and bring the figure back in a new gui window. This might be > done in a loop, incrementing the contents of the figure. > > > > See also: > > https://github.com/matplotlib/matplotlib/issues/6793 > > https://github.com/matplotlib/matplotlib/issues/6982 > > > > Eric > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Tue Apr 16 20:22:48 2019 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 16 Apr 2019 20:22:48 -0400 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> Message-ID: I don't think the ability to save after closing the GUI window has always worked. In fact, I have always taught students to perform a savefig prior to doing `plt.show()` if you want to programmatically save a figure and display it. I'd be perfectly fine with killing off that mis-feature. To me, closing a figure window should be equivalent to calling `fig.close()`. If you wanted to save the figure after closing the gui window, you could easily do it from the save file button. On Tue, Apr 16, 2019 at 12:02 PM Antony Lee wrote: > Hi, > It's actually not clear to me how GUI-closing and really closing are > related (unless we decided that GUI closing means teardown, but I don't > think we *need* that), and what the "latent figures" concept is supposed to > achieve. > Doesn't this approximately come down to > 1) when calling plt.close(fig), do fig.clf() -> ax.cla() > 2) in ax.cla(), before doing ax.lines = [], first do for line in ax.lines: > line.remove()? (and similarly for other artists) > Also, note that if one just wants to dump figures to your hard drive in a > loop, I would strongly suggest not bothering with pyplot as all and just do > "fig = matplotlib.figure.Figure(); ax = fig.subplots(); etc." The main > issue with this approach is that it's a bit awkward to pop up a figure if > one decides, after all, that they want to interactively play with it; a > possibility would be to allow pyplot to "adopt" figures in a post-hoc > manner via plt.show([fig1, fig2, ...]) ( > https://github.com/matplotlib/matplotlib/pull/13590#issuecomment-469497636 > ). > Antony > > On Tue, Apr 16, 2019 at 5:41 PM Jody Klymak wrote: > >> I think if it makes our lives easier the paradigm that a closed window >> means the figure is closed programmatically is pretty straightforward and >> standard across GUI interfaces. If folks need a workflow where they access >> the figure while it?s open they can turn off blocking. I vote we keep it >> simple and predictable rather than tie ourselves in knots with complicated >> ways of keeping track of what we think the user may want to do. >> >> Cheers. Jody >> >> Sent from my iPhone >> >> > On Apr 16, 2019, at 12:19 AM, Eric Firing wrote: >> > >> > >> > In today's weekly meeting, with Hannah, Thomas, and myself, we >> discussed https://github.com/matplotlib/matplotlib/issues/8519, which >> points to the long-standing problem that matplotlib relies on garbage >> collection to release memory after a figure is closed. With some >> work-flows the automatic collection doesn't happen often enough and the >> user must explicitly trigger it. It would be better if pyplot cleaned up >> after itself, breaking reference cycles when a figure is closed. I think >> it is time to make this change, so I marked the issue "Release-critical". I >> am hoping we can get this done as a high-priority task, *early* in the 3.2 >> cycle. >> > >> > The central point is that closing a figure should clear it, and >> clearing it should recursively walk through the children, breaking >> connections and reference cycles all the way down. One possibility would >> be to modify or replace the figure object such that any attempt to operate >> on the figure after closing would fail by raising an informative exception. >> > >> > Question: should closing the gui window also close the figure? No, >> because that would prevent the user from calling savefig on it. This would >> interfere with a reasonable use-case, in which plt.show is used in blocking >> mode, the window is closed, and the figure is saved via savefig. Problem: >> if closing the gui window doesn't close the figure, how can it ever be >> closed? >> > >> > This leads to the suggestion that the pyplot state manager keep a list >> of "latent figures" which are no longer displayed in a gui window but have >> not been closed. They could then be explicitly closed by >> "plt.close('all')". This also opens the possibility for an API allowing >> one to re-display a figure after closing its gui window. For example, one >> might do a calculation, show it in a figure in a blocking window with >> "plt.show", close the window, do additional calculations, add them to the >> same figure, and bring the figure back in a new gui window. This might be >> done in a loop, incrementing the contents of the figure. >> > >> > See also: >> > https://github.com/matplotlib/matplotlib/issues/6793 >> > https://github.com/matplotlib/matplotlib/issues/6982 >> > >> > Eric >> > _______________________________________________ >> > Matplotlib-devel mailing list >> > Matplotlib-devel at python.org >> > https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aktiophi at gmail.com Thu Apr 18 18:44:08 2019 From: aktiophi at gmail.com (UE MOVIES) Date: Thu, 18 Apr 2019 15:44:08 -0700 Subject: [Matplotlib-devel] matplotlib qt trading terminal; finance sample In-Reply-To: References: Message-ID: Hello Lists, Attached you find the new lightning fast latest version of the bitcoin / altcoin trading terminal that can be consulted as a quite nice matplotlib charting example and how to embed matplotlib in QT4. The current version supports python3 + matplotlib-3.0.3. Features of the trading terminal: coins inside multiple tabs, candlestick/heikin ashi, trending & oscillating indicators, orderbook, active buy/sell, any missing feature will be added, feel free to modify the source code. Google Notice: Wavetrend Robot With Kind Regards, Aktiophi On Tue, Oct 23, 2018 at 11:18 PM cerberus cerberus wrote: > > Hello Lists, > > I will park my matplotlib source code for a trading terminal written in python2/matplotlib/pyqt4 here > in case one needs reasonable good reference code about how to plot financial candlestick charts and > indicators with matplotlib and qt. > A sample of a combined orderbook for several crypto currency exchanges is included, > see attached screenshot. > > Google Notice: Wavetrend Robot. > > With Kind Regards, > > Aktiophi > -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.png Type: image/png Size: 239594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wavetrend-rc1.zip Type: application/x-zip-compressed Size: 1146151 bytes Desc: not available URL: From pmhobson at gmail.com Thu Apr 18 19:35:28 2019 From: pmhobson at gmail.com (Paul Hobson) Date: Thu, 18 Apr 2019 16:35:28 -0700 Subject: [Matplotlib-devel] matplotlib qt trading terminal; finance sample In-Reply-To: References: Message-ID: This is pretty sketchy. Can we remove messages from the archives? If so, I nominate this for removal. On Thu, Apr 18, 2019 at 3:44 PM UE MOVIES wrote: > Hello Lists, > > Attached you find the new lightning fast latest version of the bitcoin > / altcoin trading terminal that can be consulted > as a quite nice matplotlib charting example and how to embed matplotlib in > QT4. > The current version supports python3 + matplotlib-3.0.3. > Features of the trading terminal: coins inside multiple tabs, > candlestick/heikin ashi, trending & oscillating indicators, > orderbook, active buy/sell, any missing feature will be added, feel > free to modify the source code. > > Google Notice: Wavetrend Robot > > With Kind Regards, > > Aktiophi > > On Tue, Oct 23, 2018 at 11:18 PM cerberus cerberus > wrote: > > > > Hello Lists, > > > > I will park my matplotlib source code for a trading terminal written in > python2/matplotlib/pyqt4 here > > in case one needs reasonable good reference code about how to plot > financial candlestick charts and > > indicators with matplotlib and qt. > > A sample of a combined orderbook for several crypto currency exchanges > is included, > > see attached screenshot. > > > > Google Notice: Wavetrend Robot. > > > > With Kind Regards, > > > > Aktiophi > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aktiophi at gmail.com Thu Apr 18 22:46:51 2019 From: aktiophi at gmail.com (UE MOVIES) Date: Thu, 18 Apr 2019 19:46:51 -0700 Subject: [Matplotlib-devel] matplotlib qt trading terminal; finance sample In-Reply-To: References: Message-ID: Hello Lists, The trading terminal project is available here: https://git.launchpad.net/~cerberuz/+git/wavetrend including bugfixes and up-to-date code. Thank you X (last E-Mail to this list) On Thu, Apr 18, 2019 at 4:34 PM Paul Hobson wrote: > > This is pretty sketchy. Can we remove messages from the archives? If so, I nominate this for removal. > > On Thu, Apr 18, 2019 at 3:44 PM UE MOVIES wrote: >> >> Hello Lists, >> >> Attached you find the new lightning fast latest version of the bitcoin >> / altcoin trading terminal that can be consulted >> as a quite nice matplotlib charting example and how to embed matplotlib in QT4. >> The current version supports python3 + matplotlib-3.0.3. >> Features of the trading terminal: coins inside multiple tabs, >> candlestick/heikin ashi, trending & oscillating indicators, >> orderbook, active buy/sell, any missing feature will be added, feel >> free to modify the source code. >> >> Google Notice: Wavetrend Robot >> >> With Kind Regards, >> >> Aktiophi >> >> On Tue, Oct 23, 2018 at 11:18 PM cerberus cerberus wrote: >> > >> > Hello Lists, >> > >> > I will park my matplotlib source code for a trading terminal written in python2/matplotlib/pyqt4 here >> > in case one needs reasonable good reference code about how to plot financial candlestick charts and >> > indicators with matplotlib and qt. >> > A sample of a combined orderbook for several crypto currency exchanges is included, >> > see attached screenshot. >> > >> > Google Notice: Wavetrend Robot. >> > >> > With Kind Regards, >> > >> > Aktiophi >> > >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From tcaswell at gmail.com Fri Apr 19 17:39:34 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 19 Apr 2019 17:39:34 -0400 Subject: [Matplotlib-devel] [Ann] Matplotlib 3.1.0rc1 tagged Message-ID: Folks, I have (finally) tagged 3.1.0rc1 ! See https://matplotlib.org/devdocs/api/api_changes.html and https://matplotlib.org/devdocs/users/whats_new.html for drafts of the api changes and whats new. A big thanks to Hannah Aizenman and David Stansby for pulling the documentation together! As this is a pre-release I am going to put the tarball up on pypi without waiting for the wheels. The wheels and the conda-forge packages will go up as they are ready (and will announce more widely at that point). Let's aim from 3.1.0 final in the first week of May. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sat Apr 20 18:44:57 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 20 Apr 2019 18:44:57 -0400 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> Message-ID: Some of the tools in https://medium.com/zendesk-engineering/hunting-for-memory-leaks-in-python-applications-6824d0518774 May be useful for working on this. Tom On Tue, Apr 16, 2019, 20:23 Benjamin Root wrote: > I don't think the ability to save after closing the GUI window has always > worked. In fact, I have always taught students to perform a savefig prior > to doing `plt.show()` if you want to programmatically save a figure and > display it. I'd be perfectly fine with killing off that mis-feature. To me, > closing a figure window should be equivalent to calling `fig.close()`. If > you wanted to save the figure after closing the gui window, you could > easily do it from the save file button. > > > On Tue, Apr 16, 2019 at 12:02 PM Antony Lee > wrote: > >> Hi, >> It's actually not clear to me how GUI-closing and really closing are >> related (unless we decided that GUI closing means teardown, but I don't >> think we *need* that), and what the "latent figures" concept is supposed to >> achieve. >> Doesn't this approximately come down to >> 1) when calling plt.close(fig), do fig.clf() -> ax.cla() >> 2) in ax.cla(), before doing ax.lines = [], first do for line in >> ax.lines: line.remove()? (and similarly for other artists) >> Also, note that if one just wants to dump figures to your hard drive in a >> loop, I would strongly suggest not bothering with pyplot as all and just do >> "fig = matplotlib.figure.Figure(); ax = fig.subplots(); etc." The main >> issue with this approach is that it's a bit awkward to pop up a figure if >> one decides, after all, that they want to interactively play with it; a >> possibility would be to allow pyplot to "adopt" figures in a post-hoc >> manner via plt.show([fig1, fig2, ...]) ( >> https://github.com/matplotlib/matplotlib/pull/13590#issuecomment-469497636 >> ). >> Antony >> >> On Tue, Apr 16, 2019 at 5:41 PM Jody Klymak wrote: >> >>> I think if it makes our lives easier the paradigm that a closed window >>> means the figure is closed programmatically is pretty straightforward and >>> standard across GUI interfaces. If folks need a workflow where they access >>> the figure while it?s open they can turn off blocking. I vote we keep it >>> simple and predictable rather than tie ourselves in knots with complicated >>> ways of keeping track of what we think the user may want to do. >>> >>> Cheers. Jody >>> >>> Sent from my iPhone >>> >>> > On Apr 16, 2019, at 12:19 AM, Eric Firing wrote: >>> > >>> > >>> > In today's weekly meeting, with Hannah, Thomas, and myself, we >>> discussed https://github.com/matplotlib/matplotlib/issues/8519, which >>> points to the long-standing problem that matplotlib relies on garbage >>> collection to release memory after a figure is closed. With some >>> work-flows the automatic collection doesn't happen often enough and the >>> user must explicitly trigger it. It would be better if pyplot cleaned up >>> after itself, breaking reference cycles when a figure is closed. I think >>> it is time to make this change, so I marked the issue "Release-critical". I >>> am hoping we can get this done as a high-priority task, *early* in the 3.2 >>> cycle. >>> > >>> > The central point is that closing a figure should clear it, and >>> clearing it should recursively walk through the children, breaking >>> connections and reference cycles all the way down. One possibility would >>> be to modify or replace the figure object such that any attempt to operate >>> on the figure after closing would fail by raising an informative exception. >>> > >>> > Question: should closing the gui window also close the figure? No, >>> because that would prevent the user from calling savefig on it. This would >>> interfere with a reasonable use-case, in which plt.show is used in blocking >>> mode, the window is closed, and the figure is saved via savefig. Problem: >>> if closing the gui window doesn't close the figure, how can it ever be >>> closed? >>> > >>> > This leads to the suggestion that the pyplot state manager keep a list >>> of "latent figures" which are no longer displayed in a gui window but have >>> not been closed. They could then be explicitly closed by >>> "plt.close('all')". This also opens the possibility for an API allowing >>> one to re-display a figure after closing its gui window. For example, one >>> might do a calculation, show it in a figure in a blocking window with >>> "plt.show", close the window, do additional calculations, add them to the >>> same figure, and bring the figure back in a new gui window. This might be >>> done in a loop, incrementing the contents of the figure. >>> > >>> > See also: >>> > https://github.com/matplotlib/matplotlib/issues/6793 >>> > https://github.com/matplotlib/matplotlib/issues/6982 >>> > >>> > Eric >>> > _______________________________________________ >>> > Matplotlib-devel mailing list >>> > Matplotlib-devel at python.org >>> > https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Sat Apr 20 19:38:58 2019 From: efiring at hawaii.edu (Eric Firing) Date: Sat, 20 Apr 2019 13:38:58 -1000 Subject: [Matplotlib-devel] High priority for 3.2: figure cleanup In-Reply-To: References: <2e0edc7f-349f-8652-e46c-7e41fe80ff0a@hawaii.edu> <5b38b559-7739-27bd-a0e9-294f6f4c6400@hawaii.edu> Message-ID: <26070c0a-bf47-016e-53ad-8ce1f04e1223@hawaii.edu> I think that this cleanup can be approached in parts, some of which involve refactoring so as to reduce the number of circular references. Looking at ticker.py, for example, I suspect that a cleaner implementation would eliminate the need for a Formatter or Locator to have an actual or dummy Axis as an attribute. Instead, the Axis reference, or, ideally, the information actually needed from an Axis, could be passed as kwargs to the methods that require that information. Can we get there from here, or would the deprecation/backwards-compatibility dance be too exhausting? Eric On 2019/04/20 12:44 PM, Thomas Caswell wrote: > Some of the tools in > > https://medium.com/zendesk-engineering/hunting-for-memory-leaks-in-python-applications-6824d0518774 > > May be useful for working on this. > > Tom > > On Tue, Apr 16, 2019, 20:23 Benjamin Root > wrote: > > I don't think the ability to save after closing the GUI window has > always worked. In fact, I have always taught students to perform a > savefig prior to doing `plt.show()` if you want to programmatically > save a figure and display it. I'd be perfectly fine with killing off > that mis-feature. To me, closing a figure window should be > equivalent to calling `fig.close()`. If you wanted to save the > figure after closing the gui window, you could easily do it from the > save file button. > > > On Tue, Apr 16, 2019 at 12:02 PM Antony Lee > > wrote: > > Hi, > It's actually not clear to me how GUI-closing and really closing > are related (unless we decided that GUI closing means teardown, > but I don't think we *need* that), and what the "latent figures" > concept is supposed to achieve. > Doesn't this approximately come down to > 1) when calling plt.close(fig), do fig.clf() -> ax.cla() > 2) in ax.cla(), before doing ax.lines = [], first do for line in > ax.lines: line.remove()? (and similarly for other artists) > Also, note that if one just wants to dump figures to your hard > drive in a loop, I would strongly suggest not bothering with > pyplot as all and just do "fig = matplotlib.figure.Figure(); ax > = fig.subplots(); etc."? The main issue with this approach is > that it's a bit awkward to pop up a figure if one decides, after > all, that they want to interactively play with it; a possibility > would be to allow pyplot to "adopt" figures in a post-hoc manner > via plt.show([fig1, fig2, ...]) > (https://github.com/matplotlib/matplotlib/pull/13590#issuecomment-469497636). > Antony > > On Tue, Apr 16, 2019 at 5:41 PM Jody Klymak > wrote: > > I think if it makes our lives easier the paradigm that a > closed window means the figure is closed programmatically is > pretty straightforward and standard across GUI interfaces. > If folks need a workflow where they access the figure while > it?s open they can turn off blocking.? I vote we keep it > simple and predictable rather than tie ourselves in knots > with complicated ways of keeping track of what we think the > user may want to do. > > Cheers.? Jody > > Sent from my iPhone > > > On Apr 16, 2019, at 12:19 AM, Eric Firing > > wrote: > > > > > > In today's weekly meeting, with Hannah, Thomas, and > myself, we discussed > https://github.com/matplotlib/matplotlib/issues/8519, which > points to the long-standing problem that matplotlib relies > on garbage collection to release memory after a figure is > closed.? With some work-flows the automatic collection > doesn't happen often enough and the user must explicitly > trigger it.? It would be better if pyplot cleaned up after > itself, breaking reference cycles when a figure is closed. > I think it is time to make this change, so I marked the > issue "Release-critical". I am hoping we can get this done > as a high-priority task, *early* in the 3.2 cycle. > > > > The central point is that closing a figure should clear > it, and clearing it should recursively walk through the > children, breaking connections and reference cycles all the > way down.? One possibility would be to modify or replace the > figure object such that any attempt to operate on the figure > after closing would fail by raising an informative exception. > > > > Question: should closing the gui window also close the > figure?? No, because that would prevent the user from > calling savefig on it.? This would interfere with a > reasonable use-case, in which plt.show is used in blocking > mode, the window is closed, and the figure is saved via > savefig.? Problem: if closing the gui window doesn't close > the figure, how can it ever be closed? > > > > This leads to the suggestion that the pyplot state > manager keep a list of "latent figures" which are no longer > displayed in a gui window but have not been closed.? They > could then be explicitly closed by "plt.close('all')".? This > also opens the possibility for an API allowing one to > re-display a figure after closing its gui window. For > example, one might do a calculation, show it in a figure in > a blocking window with "plt.show", close the window, do > additional calculations, add them to the same figure, and > bring the figure back in a new gui window.? This might be > done in a loop, incrementing the contents of the figure. > > > > See also: > > https://github.com/matplotlib/matplotlib/issues/6793 > > https://github.com/matplotlib/matplotlib/issues/6982 > > > > Eric > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel >