From quantum.analyst at gmail.com Sat Oct 2 04:02:07 2021 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Sat, 2 Oct 2021 04:02:07 -0400 Subject: [Matplotlib-devel] [ANN] Matplotlib 3.5.0 release candidate 1 Message-ID: Hi all, We are pleased to announce the issue of the first release candidate for 3.5.0. Please test widely so that we may correct any bugs before the final release. Pre-built wheels are available for most major platforms, and can be installed using `pip install matplotlib==3.5.0rc1`. Other packages may also be available already; please check with your preferred source. The 3.3.0 release represents the work of 130 authors over 781 pull requests, and we thank them for their contributions. Some highlights of this release include: * We have switched to the pydata-sphinx-theme for the documentation. There may be some kinks to shake out still; please report a bug if anything is missing. * Figures have a `draw_without_rendering` method * New `Annulus` patch * New arrow styles in `ArrowStyle` and `ConnectionPath` * New colormap registry * Image interpolation is now possible at the RGBA stage * Tick positions and labels can be set simultaneously in `set_ticks` * More configurability of legend title and label colours * Type 42 subsetting is now enabled for the PDF & PS backends; this is one outcome of this year's GSoC. Thanks Aitik Gupta! * A slew of interactive tool improvements for the Slider widgets, and *Selector widgets, thanks to Eric Prestat! * Axes3D draw order and orientation can be manually controlled * Added GTK4 and Qt6 backends and HiDPI support to GTK backends, removal of Qt4 backend For further details, please see the What's new in Matplotlib 3.5.0 page: https://matplotlib.org/3.5.0/users/whats_new.html and the milestone on GitHub: https://github.com/matplotlib/matplotlib/milestone/59?closed=1 For packagers, this release contains some changes to dependencies: * NumPy 1.17 is now required. * Tk 8.4 is now required, when used. * The fontTools package is now required for font subsetting. * The underscore LaTeX package is now required for usetex output. * Matplotlib-specific build options have moved from setup.cfg to mplsetup.cfg, by default. 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. From rayosborn at mac.com Mon Oct 11 20:16:06 2021 From: rayosborn at mac.com (Raymond Osborn) Date: Mon, 11 Oct 2021 19:16:06 -0500 Subject: [Matplotlib-devel] Catching parsing errors in Mathtext Message-ID: When testing v3.5.0rc1, I had a fright when my plots suddenly disappeared while attempting to change their title with ax.set_title. It turned out that this occurred because of a typo in the title text; I had closed a brace with a parenthesis by mistake. However, I was puzzled why this hadn?t triggered an exception. In the debugger, it looks as if this is because the exception was caught when calling draw_idle, but was never reraised because context managers stopped it. For some reason, errors do get raised when I run Pyplot in IPython with the same typo, but I haven?t worked out yet why embedding Matplotlib stops them appearing. Instead, the plot just disappears when I click on the PyQt canvas. The point of this post is too ask whether it might not be better to call the pyparsing module earlier in this process so that the user is immediately alerted to the invalid text rather than waiting for an attempted redraw. I don?t know enough about the text rendering engine to know whether there are reasons this is not possible, so I thought I would ask the question. Shouldn?t any call to set_title, set_xlabel, etc, immediately warn the user that the text doesn?t parse? If this is an efficiency issue, couldn?t the parsing result be cached in the Text object? With regards, Ray Osborn From antony.lee at institutoptique.fr Tue Oct 12 04:03:57 2021 From: antony.lee at institutoptique.fr (Antony Lee) Date: Tue, 12 Oct 2021 10:03:57 +0200 Subject: [Matplotlib-devel] Catching parsing errors in Mathtext In-Reply-To: References: Message-ID: Hi, Currently there is no "intermediate format" that would allow generic caching: 1) when the text object is created, we don't know yet whether it will ultimately be rendered on screen or to a bitmap or a vector file, and 2) when rendering to a vector format (pdf, ps, svg), we do cache the individual glyphs, but when rendering to a bitmap (screen, png), we directly convert the expression to a bitmap, and there is no code to instead convert individual glyphs to a bitmap. In fact, I do have some vague project of having a list-of-glyphs intermediate format, but that'll require quite a bit of refactoring. Cheers, Antony On Tue, Oct 12, 2021 at 2:16 AM Raymond Osborn via Matplotlib-devel < matplotlib-devel at python.org> wrote: > When testing v3.5.0rc1, I had a fright when my plots suddenly disappeared > while attempting to change their title with ax.set_title. It turned out > that this occurred because of a typo in the title text; I had closed a > brace with a parenthesis by mistake. However, I was puzzled why this hadn?t > triggered an exception. In the debugger, it looks as if this is because the > exception was caught when calling draw_idle, but was never reraised because > context managers stopped it. For some reason, errors do get raised when I > run Pyplot in IPython with the same typo, but I haven?t worked out yet why > embedding Matplotlib stops them appearing. Instead, the plot just > disappears when I click on the PyQt canvas. > > The point of this post is too ask whether it might not be better to call > the pyparsing module earlier in this process so that the user is > immediately alerted to the invalid text rather than waiting for an > attempted redraw. I don?t know enough about the text rendering engine to > know whether there are reasons this is not possible, so I thought I would > ask the question. Shouldn?t any call to set_title, set_xlabel, etc, > immediately warn the user that the text doesn?t parse? If this is an > efficiency issue, couldn?t the parsing result be cached in the Text object? > > With regards, > Ray Osborn > > > _______________________________________________ > 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 jklymak at uvic.ca Tue Oct 12 04:47:10 2021 From: jklymak at uvic.ca (Jody Klymak) Date: Tue, 12 Oct 2021 10:47:10 +0200 Subject: [Matplotlib-devel] Catching parsing errors in Mathtext In-Reply-To: References: Message-ID: <7A0C8F1F-4F39-444B-8184-50CE517B6F38@uvic.ca> Jupyter also does this ```python import matplotlib.pyplot as plt import numpy as np import matplotlib as mpl fig, ax = plt.subplots() ax.plot(np.arange(10)) ax.set_title(r'Boo $\[a\]$') plt.show() ``` silently fails to produce a plot. Directly running as a script yields: ``` ValueError: \[a\] ^ Unknown symbol: \[, found '\' (at char 0), (line:1, col:1) ``` Is it a huge efficiency penalty to simply parse the text twice, once at creation, and once at draw? Cheers, Jody > On Oct 12, 2021, at 10:03 AM, Antony Lee wrote: > > Hi, > Currently there is no "intermediate format" that would allow generic caching: 1) when the text object is created, we don't know yet whether it will ultimately be rendered on screen or to a bitmap or a vector file, and 2) when rendering to a vector format (pdf, ps, svg), we do cache the individual glyphs, but when rendering to a bitmap (screen, png), we directly convert the expression to a bitmap, and there is no code to instead convert individual glyphs to a bitmap. In fact, I do have some vague project of having a list-of-glyphs intermediate format, but that'll require quite a bit of refactoring. > Cheers, > Antony > > On Tue, Oct 12, 2021 at 2:16 AM Raymond Osborn via Matplotlib-devel > wrote: > When testing v3.5.0rc1, I had a fright when my plots suddenly disappeared while attempting to change their title with ax.set_title. It turned out that this occurred because of a typo in the title text; I had closed a brace with a parenthesis by mistake. However, I was puzzled why this hadn?t triggered an exception. In the debugger, it looks as if this is because the exception was caught when calling draw_idle, but was never reraised because context managers stopped it. For some reason, errors do get raised when I run Pyplot in IPython with the same typo, but I haven?t worked out yet why embedding Matplotlib stops them appearing. Instead, the plot just disappears when I click on the PyQt canvas. > > The point of this post is too ask whether it might not be better to call the pyparsing module earlier in this process so that the user is immediately alerted to the invalid text rather than waiting for an attempted redraw. I don?t know enough about the text rendering engine to know whether there are reasons this is not possible, so I thought I would ask the question. Shouldn?t any call to set_title, set_xlabel, etc, immediately warn the user that the text doesn?t parse? If this is an efficiency issue, couldn?t the parsing result be cached in the Text object? > > With regards, > Ray Osborn > > > _______________________________________________ > 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 antony.lee at institutoptique.fr Tue Oct 12 04:48:57 2021 From: antony.lee at institutoptique.fr (Antony Lee) Date: Tue, 12 Oct 2021 10:48:57 +0200 Subject: [Matplotlib-devel] Catching parsing errors in Mathtext In-Reply-To: <7A0C8F1F-4F39-444B-8184-50CE517B6F38@uvic.ca> References: <7A0C8F1F-4F39-444B-8184-50CE517B6F38@uvic.ca> Message-ID: Parsing twice is probably OK, although I'm more puzzled by why jupyter swallows the error, which seems like something worth fixing regardless. Antony On Tue, Oct 12, 2021 at 10:47 AM Jody Klymak wrote: > Jupyter also does this > > ```python > import matplotlib.pyplot as plt > import numpy as np > import matplotlib as mpl > > fig, ax = plt.subplots() > ax.plot(np.arange(10)) > ax.set_title(r'Boo $\[a\]$') > plt.show() > ``` > > silently fails to produce a plot. > > Directly running as a script yields: > > ``` > ValueError: > \[a\] > ^ > Unknown symbol: \[, found '\' (at char 0), (line:1, col:1) > ``` > > Is it a huge efficiency penalty to simply parse the text twice, once at > creation, and once at draw? > > Cheers, Jody > > On Oct 12, 2021, at 10:03 AM, Antony Lee > wrote: > > Hi, > Currently there is no "intermediate format" that would allow generic > caching: 1) when the text object is created, we don't know yet whether it > will ultimately be rendered on screen or to a bitmap or a vector file, and > 2) when rendering to a vector format (pdf, ps, svg), we do cache the > individual glyphs, but when rendering to a bitmap (screen, png), we > directly convert the expression to a bitmap, and there is no code to > instead convert individual glyphs to a bitmap. In fact, I do have some > vague project of having a list-of-glyphs intermediate format, but that'll > require quite a bit of refactoring. > Cheers, > Antony > > On Tue, Oct 12, 2021 at 2:16 AM Raymond Osborn via Matplotlib-devel < > matplotlib-devel at python.org> wrote: > >> When testing v3.5.0rc1, I had a fright when my plots suddenly disappeared >> while attempting to change their title with ax.set_title. It turned out >> that this occurred because of a typo in the title text; I had closed a >> brace with a parenthesis by mistake. However, I was puzzled why this hadn?t >> triggered an exception. In the debugger, it looks as if this is because the >> exception was caught when calling draw_idle, but was never reraised because >> context managers stopped it. For some reason, errors do get raised when I >> run Pyplot in IPython with the same typo, but I haven?t worked out yet why >> embedding Matplotlib stops them appearing. Instead, the plot just >> disappears when I click on the PyQt canvas. >> >> The point of this post is too ask whether it might not be better to call >> the pyparsing module earlier in this process so that the user is >> immediately alerted to the invalid text rather than waiting for an >> attempted redraw. I don?t know enough about the text rendering engine to >> know whether there are reasons this is not possible, so I thought I would >> ask the question. Shouldn?t any call to set_title, set_xlabel, etc, >> immediately warn the user that the text doesn?t parse? If this is an >> efficiency issue, couldn?t the parsing result be cached in the Text object? >> >> With regards, >> Ray Osborn >> >> >> _______________________________________________ >> 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 tcaswell at gmail.com Fri Oct 15 09:57:59 2021 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 15 Oct 2021 09:57:59 -0400 Subject: [Matplotlib-devel] Run sprint at pydata global 2021 Message-ID: Folks, Pydata Global [1] is in 2 weeks (Oct 28-30). Is anyone interested in leading the sprint at the event? The time commitment is a 4 hour block of time anywhere in those three days. I had planned to run the sprint, however from when I volunteered to run it and now I have accumulated several conflicts I can not preempt. Tom P.S. should be a good conference if you want to just attend! [1] https://pydata.org/global2021/ -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Oct 20 15:52:29 2021 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 20 Oct 2021 15:52:29 -0400 Subject: [Matplotlib-devel] Minor history re-writing + renaming default branch Message-ID: Folks, Elliott and I are in the process of implementing the changes discussed in https://discourse.matplotlib.org/t/minor-re-writing-of-history-and-moving-from-master-to-main-for-default-branch/22354/10 . To make sure we do not get any conflicts, we have temporarily increased the required number of reviews to merge to 6. I will update when we are done. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Wed Oct 20 16:25:12 2021 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 20 Oct 2021 16:25:12 -0400 Subject: [Matplotlib-devel] Minor history re-writing + renaming default branch In-Reply-To: References: Message-ID: Folks, We are done and it appears to have worked. Any PRs that were branched from the default branch after the commits we removed will need to be rebased to remove the commits. For full details, please see https://discourse.matplotlib.org/t/minor-re-writing-of-history-and-moving-from-master-to-main-for-default-branch/22354/7 . The review threshold has been reset to 1. Below is the template that I will be posting to the affected PRs: This PR is affected by a re-writing of our history to remove a large number of accidentally committed files [see discourse]( https://discourse.matplotlib.org/t/minor-re-writing-of-history-and-moving-from-master-to-main-for-default-branch/22354/6) for details. To recover this PR it will need to be rebased onto the new default branch (main). There are several ways to accomplish this, but we recommend (assuming that you call the matplotlib/matplotlib remote `"upstream"` ```bash git remote update git checkout main git merge --ff-only upstream/main git checkout YOUR_BRANCH git rebase --onto=main upstream/old_master # git rebase -i main # if you prefer git push --force-with-lease # assuming you are tracking your branch ``` If you do not feel comfortable doing this or need any help please reach out to any of the Matplotlib developers. We can either help you with the process or do it for you. Thank you for your contributions to Matplotlib and sorry for the inconvenience. ------- The force-push to the new default branch was: 15:54:38 $ git push DANGER --force-with-lease main:main Enumerating objects: 5941, done. Counting objects: 100% (3462/3462), done. Delta compression using up to 8 threads Compressing objects: 100% (1300/1300), done. Writing objects: 100% (2876/2876), 766.75 KiB | 21.30 MiB/s, done. Total 2876 (delta 1983), reused 1962 (delta 1564), pack-reused 0 remote: Resolving deltas: 100% (1983/1983), completed with 296 local objects. To github.com:matplotlib/matplotlib.git + f6e0ee49c5...a1eef38f6f main -> main (forced update) ------ Thank you everyone for your patience, hopefully we will get through this without too much more trouble. Tom On Wed, Oct 20, 2021 at 3:52 PM Thomas Caswell wrote: > Folks, > > Elliott and I are in the process of implementing the changes discussed in > https://discourse.matplotlib.org/t/minor-re-writing-of-history-and-moving-from-master-to-main-for-default-branch/22354/10 > . > > To make sure we do not get any conflicts, we have temporarily increased > the required number of reviews to merge to 6. > > I will update when we are done. > > Tom > > -- > Thomas Caswell > tcaswell at gmail.com > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From quantum.analyst at gmail.com Thu Oct 28 23:49:04 2021 From: quantum.analyst at gmail.com (Elliott Sales de Andrade) Date: Thu, 28 Oct 2021 23:49:04 -0400 Subject: [Matplotlib-devel] [ANN] Cycler 0.11 release Message-ID: <0d21cd01-e8d8-4b21-488f-adf69a5f1ec6@gmail.com> Hi all, We are pleased to announce the release of Cycler 0.11. This is the first Cycler feature release in some years. New features include: * Added Cycler.by_key, which produces values by key (#26) * Added Cycler.__contains__, which adds support for in checks (#34) * Wheels now includes the LICENSE file (#48) * The sdist now includes the LICENSE (#58) and tests (#32) * Cycler no longer supports Python 2. Supported versions of Python are 3.6 and above. For further details, please see the milestone on GitHub: https://github.com/matplotlib/cycler/milestone/1?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: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: