From tcaswell at gmail.com Sun Jun 2 15:47:53 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 2 Jun 2019 15:47:53 -0400 Subject: [Matplotlib-devel] Matplotlib 2.2.2 - unclear license conditions for _png.cpp In-Reply-To: <617F0F9AC717D841BF586C83D0DE265E2FC2BF1E@DENBGAT9EJ5MSX.ww902.siemens.net> References: <617F0F9AC717D841BF586C83D0DE265E2FC2BF1E@DENBGAT9EJ5MSX.ww902.siemens.net> Message-ID: Johann, Thank you for being patient with us. TLDR: the relevant license file is /****************************************************************** Copyright 2000 by Object Craft P/L, Melbourne, Australia. All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Object Craft is not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. OBJECT CRAFT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL OBJECT CRAFT BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ******************************************************************/ (also attached) ---- It looks like this comment came in via https://github.com/matplotlib/matplotlib/commit/6cc5c32cc76be3e35bab7aa74f8c87a6b10125f8 in 2004 by JDH. It was then showes up a second time in 2004 https://github.com/matplotlib/matplotlib/commit/9c2d9c327a7c5d879a7bc0091fd8251fa6414e22 again by JDH. It was then moved around by MD in https://github.com/matplotlib/matplotlib/commit/22e2a424dbfd5db2dad136dc4c137b8cbae9393e and https://github.com/matplotlib/matplotlib/commit/26a14a3b1958363b5b795ec83161dfe21c6cd98f which deleted both of the other uses and unified t to it's current location in `_png.cpp` in 2008. It looks like that comment was moved from the write function to the top of the file in https://github.com/matplotlib/matplotlib/commit/ba4016014cb4fb4927e36ce8ea429fed47dcb787 . I think that this was unintentional and the comment should still just apply to the png writing function. I have pulled out the 3 versions this function when they came into the code base and attached them as v1.cpp, v2.cpp, and v3.cpp and the current state of the function in v4.cpp (re-formatted to all have the same indentation). Although it never made it into version control, the license file was included in the source releases of Matplotlib ( https://sourceforge.net/projects/matplotlib/files/matplotlib-maintenance/matplotlib-0.91.1/ ) which eventually gets us back to the source: https://www.object-craft.com.au/projects/paint/ and I have attached the relevant function as v0.cpp Tom On Fri, May 10, 2019 at 5:04 AM Arnold, Johann wrote: > Dear Matplotlib developers, > > For one of our products we want to use Matplotlib 2.2.2. In order to > distribute our product in a license compliant way we check the licenses of > all OSS source code we are using. We do this on an file by file basis. For > the file _png.cpp we have not been able to determine license situation. In > file header we found the following text: > > // this code is heavily adapted from the paint license, which is in > 4. // the file paint.license (BSD compatible) included in this > 5. // distribution. TODO, add license file to MANIFEST.in and CVS > 6. > 7. /* For linux, png.h must be imported before Python.h because > 8. png.h needs to be the one to define setjmp. > 9. Undefining _POSIX_C_SOURCE and _XOPEN_SOURCE stops a couple > 10. of harmless warnings. > > We could not find the file ?paint.license?, i.e. we do not know the > correct license for _png.cpp. Can you please help us in order to get the > correct license for _png.cpp > > Thanks a lot in advance and kind regards > Johann Arnold > > > Siemens AG > Digital Industries > Process Automation > Software House Nbg > DI PA CI R&D 3 > Gleiwitzer Str. 555 > 90475 N?rnberg, Deutschland > Tel.: +49 911 895-3162 > Fax: +49 911 895-4010 > mailto:johann.arnold at siemens.com > www.siemens.com/ingenuityforlife > [image: www.siemens.com/ingenuityforlife] > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann > Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus > Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der > Gesellschaft: Berlin und M?nchen, Deutschland; Registergericht: Berlin > Charlottenburg, HRB 12300, M?nchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v1.cpp Type: text/x-c++src Size: 2166 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v3.cpp Type: text/x-c++src Size: 3931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v2.cpp Type: text/x-c++src Size: 2107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v4.cpp Type: text/x-c++src Size: 10176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v0.cpp Type: text/x-c++src Size: 1657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LICENSE_PAINT Type: application/octet-stream Size: 1148 bytes Desc: not available URL: From tcaswell at gmail.com Sun Jun 2 15:59:32 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 2 Jun 2019 15:59:32 -0400 Subject: [Matplotlib-devel] Matplotlib 2.2.2 - unclear license conditions for _png.cpp In-Reply-To: References: <617F0F9AC717D841BF586C83D0DE265E2FC2BF1E@DENBGAT9EJ5MSX.ww902.siemens.net> Message-ID: Slight follow up (I was so happy to find the license I sent the email before crossing all of the is and dotting all of the ts), the license file did make it into version control via https://github.com/matplotlib/matplotlib/commit/29dfcd2684c42ea0fa0634ead3878e911812ace9 but was accidentally removed in https://github.com/matplotlib/matplotlib/commit/e3a5f1dd9a2f62027d747c44b3e0c4e5ccf44ba5 . I am in the process of putting in a PR to restore LICENSE_PAINT. Tom On Sun, Jun 2, 2019 at 3:47 PM Thomas Caswell wrote: > Johann, > > Thank you for being patient with us. > > TLDR: the relevant license file is > > /****************************************************************** > Copyright 2000 by Object Craft P/L, Melbourne, Australia. > > All Rights Reserved > > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose and without fee is hereby granted, > provided that the above copyright notice appear in all copies and that > both that copyright notice and this permission notice appear in > supporting documentation, and that the name of Object Craft > is not be used in advertising or publicity pertaining to > distribution of the software without specific, written prior > permission. > > OBJECT CRAFT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, > INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO > EVENT SHALL OBJECT CRAFT BE LIABLE FOR ANY SPECIAL, INDIRECT OR > CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF > USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR > OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR > PERFORMANCE OF THIS SOFTWARE. > > ******************************************************************/ > > (also attached) > > ---- > > It looks like this comment came in via > https://github.com/matplotlib/matplotlib/commit/6cc5c32cc76be3e35bab7aa74f8c87a6b10125f8 in > 2004 by JDH. > > It was then showes up a second time in 2004 > https://github.com/matplotlib/matplotlib/commit/9c2d9c327a7c5d879a7bc0091fd8251fa6414e22 again > by JDH. > > It was then moved around by MD in > https://github.com/matplotlib/matplotlib/commit/22e2a424dbfd5db2dad136dc4c137b8cbae9393e > and > https://github.com/matplotlib/matplotlib/commit/26a14a3b1958363b5b795ec83161dfe21c6cd98f which > deleted both of the other uses and unified t to it's current location in > `_png.cpp` in 2008. > > It looks like that comment was moved from the write function to the top of > the file in > https://github.com/matplotlib/matplotlib/commit/ba4016014cb4fb4927e36ce8ea429fed47dcb787 . > I think that this was unintentional and the comment should still just apply > to the png writing function. > > I have pulled out the 3 versions this function when they came into the > code base and attached them as v1.cpp, v2.cpp, and v3.cpp and the current > state of the function in v4.cpp (re-formatted to all have the same > indentation). > > Although it never made it into version control, the license file was > included in the source releases of Matplotlib ( > https://sourceforge.net/projects/matplotlib/files/matplotlib-maintenance/matplotlib-0.91.1/ ) > which eventually gets us back to the source: > https://www.object-craft.com.au/projects/paint/ and I have attached the > relevant function as v0.cpp > > Tom > > > > > > On Fri, May 10, 2019 at 5:04 AM Arnold, Johann > wrote: > >> Dear Matplotlib developers, >> >> For one of our products we want to use Matplotlib 2.2.2. In order to >> distribute our product in a license compliant way we check the licenses of >> all OSS source code we are using. We do this on an file by file basis. For >> the file _png.cpp we have not been able to determine license situation. In >> file header we found the following text: >> >> // this code is heavily adapted from the paint license, which is in >> 4. // the file paint.license (BSD compatible) included in this >> 5. // distribution. TODO, add license file to MANIFEST.in and CVS >> 6. >> 7. /* For linux, png.h must be imported before Python.h because >> 8. png.h needs to be the one to define setjmp. >> 9. Undefining _POSIX_C_SOURCE and _XOPEN_SOURCE stops a couple >> 10. of harmless warnings. >> >> We could not find the file ?paint.license?, i.e. we do not know the >> correct license for _png.cpp. Can you please help us in order to get the >> correct license for _png.cpp >> >> Thanks a lot in advance and kind regards >> Johann Arnold >> >> >> Siemens AG >> Digital Industries >> Process Automation >> Software House Nbg >> DI PA CI R&D 3 >> Gleiwitzer Str. 555 >> 90475 N?rnberg, Deutschland >> Tel.: +49 911 895-3162 >> Fax: +49 911 895-4010 >> mailto:johann.arnold at siemens.com >> www.siemens.com/ingenuityforlife >> [image: www.siemens.com/ingenuityforlife] >> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann >> Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus >> Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der >> Gesellschaft: Berlin und M?nchen, Deutschland; Registergericht: Berlin >> Charlottenburg, HRB 12300, M?nchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > > -- > Thomas Caswell > tcaswell at gmail.com > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 3536 bytes Desc: not available URL: From anntzer.lee at gmail.com Mon Jun 3 17:50:07 2019 From: anntzer.lee at gmail.com (Antony Lee) Date: Mon, 3 Jun 2019 23:50:07 +0200 Subject: [Matplotlib-devel] Looking for OSX and Jupyter notebook experts for integrating a new renderer into Matplotlib Message-ID: Hi all, Some of you may already have heard about mplcairo ( https://github.com/matplotlib/mplcairo), a new backend for Matplotlib I have been developing for the past two years. Briefly, it relies on the cairo library (https://www.cairographics.org/) to generate higher quality images than Matplotlib's current backends, both in raster format (for which Matplotlib currently uses Agg, a library that whose development has stalled) and in vector (PDF, PS, SVG) formats (for which Matplotlib currently uses hand-written backends). (A list of mplcairo's features and differences from Matplotlib's default backends is listed in its README, at https://github.com/matplotlib/mplcairo.) Given mplcairo's features, there is interest in the Matplotlib core developer team to move it into Matplotlib itself, with the ultimate goal to (possibly) make it the default backend. Obviously, there are many steps before this can happen, but, in particular, there are two for which I am looking for help: - Improve the macOS build: Currently, I provide wheels for Linux and Windows, but am unable to provide wheels for macOS. Briefly, this is because mplcairo depends on a C++17-compliant C++ standard library, which is not available on OSX<10.14. On Linux, this is handled by statically linking a recent enough libstdc++ into the wheel, but I have not been able to do so on maxOS (I do not work on that platform...). If anyone knows how to make this work on macOS, their help would be greatly appreciated. - Improve integration with the Jupyter notebook: Currently, Jupyter notebook's Matplotlib integration hard-codes the renderer to use to Agg. At some point, I had tried to make the notebook use mplcairo instead by forcefully overwriting the contents of the Agg backend with the mplcairo backend (ugh), which worked for a while, but things have changed enough on the notebook side (I believe) that this is not working anymore. Probably a more correct solution would be to make the backend actually properly configurable on the notebook's side. Given that I personally hardly ever use the notebook as well, here again help from a notebook expert would be most welcome. Matplotlib brownie points for any helping hands :-) Thanks in advance, Antony Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Jun 3 23:59:06 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 3 Jun 2019 23:59:06 -0400 Subject: [Matplotlib-devel] Matplotlib 2.2.x caretaker Message-ID: Folks, We discovered today that the 2.2.x branch has bit-rotted again and does not pass CI anymore (due to testing dependencies moving under us). Looking for a volunteer to take the lead on making sure that 2.2.x stays healthy, managing any 2.2.x release we want to do before 2020, and keeping track of what things from master need to be pulled all the way back. I suspect that this will take an hour per week average and is time-boxed to end on Jan 1, 2020. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Tue Jun 4 00:11:56 2019 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 3 Jun 2019 21:11:56 -0700 Subject: [Matplotlib-devel] Matplotlib 2.2.x caretaker In-Reply-To: References: Message-ID: On Mon, Jun 3, 2019 at 8:59 PM Thomas Caswell wrote: > > Folks, > > We discovered today that the 2.2.x branch has bit-rotted again and does not pass CI anymore (due to testing dependencies moving under us). I'm not volunteering, but I highly recommend dependabot for handling these things. Basically the way it works is: - rename your existing blah-requirements.txt files to blah-requirements.in - install pip-tools and run 'pip-compile blah-requrements.in' to generate a fully-specified blah-requirements.txt - enable the dependabot app on your repo Now you're always testing against an exact known version, and when your test dependencies make a new release, dependabot sends a PR to update your requirements file ? so in the cases where previously your CI would have broken, now you get a PR with failing tests to alert you to the problem, and in the mean time any other PRs keep using the old version until you get things sorted out. You can also configure dependabot to auto-merge its PRs if they pass CI, so this doesn't necessarily create any extra human workload. Getting it to send PRs to non-default branches is possible, but a little non-obvious, the details are here: https://github.com/dependabot/feedback/issues/463 -n -- Nathaniel J. Smith -- https://vorpus.org From swfiua at gmail.com Thu Jun 13 11:01:08 2019 From: swfiua at gmail.com (swfiua at gmail.com) Date: Thu, 13 Jun 2019 11:01:08 -0400 Subject: [Matplotlib-devel] Pull requests for table.py Message-ID: Hi, I just wanted to provide some background on the recent flurry of fixes to table.py and the history behind the code. See attached pdf. There are 3 main themes to the changes: * better automatic setting of the font size * change how horizontal padding around cell text is calculated * add ability to specify cell edge colours John -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tabledotpy.pdf Type: application/pdf Size: 59879 bytes Desc: not available URL: From swfiua at gmail.com Thu Jun 13 11:13:01 2019 From: swfiua at gmail.com (swfiua at gmail.com) Date: Thu, 13 Jun 2019 11:13:01 -0400 Subject: [Matplotlib-devel] image_comparison tests Message-ID: Hi, It was drawn to my attention that the baseline_images with the expected images can gobble up a lot of repository space, so it is best to squash commits to avoid submitting multiple changes to the baseline_images. Looking at all the tests that use image_comparison, almost all of them go with the default value of "tol = 0", in other words anything but an exact match generates an error. If we only cared about spotting changes then for these tests we could just store some sort of checksum on the image data and use that to spot when the image has changed. Updating a checkum only adds a few bytes to the repository. The down side of this approach (and it is a big downside) is that when an image changes you would no longer have the expected image and the diff available to look at. The only solution I can think to that is to store the expected images somewhere else, with the ability to retrieve an image given the checksum, thus keeping them out of the main repository. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.lee at institutoptique.fr Thu Jun 13 11:42:00 2019 From: antony.lee at institutoptique.fr (Antony Lee) Date: Thu, 13 Jun 2019 17:42:00 +0200 Subject: [Matplotlib-devel] Pull requests for table.py In-Reply-To: References: Message-ID: Hi John, Thanks for your writeup. It provides an interesting historical view on one of the oldest parts of the Matplotlib codebase, which is always nice read about. It is great that you intend to work again on table.py (which was mostly abandoned by the other core devs), but I am not sure to what extent the new API you propose has been stabilized, or whether you are still experimenting with it. There are also other issues with the API design (e.g. https://github.com/matplotlib/matplotlib/issues/12931) that you may, perhaps, want to revisit? As you may have noticed, making backwards incompatible changes to Matplotlib is a bit of an onerous process (due to the deprecation process, the baseline images problem, etc.). Given that table.py is fairly self-contained, perhaps you may want to consider moving it to its own separate package? i.e. something published separately on PyPI (let us know if you need any help for that), so that one would do (for example) from mpltable import table table(...) This way you can play with the API in whatever way you want, and we could just point to your package as the "new, more modern" way to make tables with Matplotlib, and possibly import it back to the main repo as a single PR once everything is stabilized. Antony On Thu, Jun 13, 2019 at 5:01 PM swfiua at gmail.com wrote: > Hi, > > I just wanted to provide some background on the recent flurry of fixes to > table.py and the history behind the code. > > See attached pdf. > > There are 3 main themes to the changes: > > * better automatic setting of the font size > * change how horizontal padding around cell text is calculated > * add ability to specify cell edge colours > > John > _______________________________________________ > 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 Thu Jun 13 12:03:51 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 13 Jun 2019 12:03:51 -0400 Subject: [Matplotlib-devel] Pull requests for table.py In-Reply-To: References: Message-ID: John, I will also add that if you want to got the stand-alone package route we can put the repo under the Matplotlib org and give you full control of it. Tom On Thu, Jun 13, 2019 at 11:51 AM Antony Lee wrote: > Hi John, > > Thanks for your writeup. It provides an interesting historical view on > one of the oldest parts of the Matplotlib codebase, which is always nice > read about. > > It is great that you intend to work again on table.py (which was mostly > abandoned by the other core devs), but I am not sure to what extent the new > API you propose has been stabilized, or whether you are still experimenting > with it. There are also other issues with the API design (e.g. > https://github.com/matplotlib/matplotlib/issues/12931) that you may, > perhaps, want to revisit? > > As you may have noticed, making backwards incompatible changes to > Matplotlib is a bit of an onerous process (due to the deprecation process, > the baseline images problem, etc.). Given that table.py is fairly > self-contained, perhaps you may want to consider moving it to its own > separate package? i.e. something published separately on PyPI (let us know > if you need any help for that), so that one would do (for example) > > from mpltable import table > table(...) > > > This way you can play with the API in whatever way you want, and we could > just point to your package as the "new, more modern" way to make tables > with Matplotlib, and possibly import it back to the main repo as a single > PR once everything is stabilized. > > Antony > > On Thu, Jun 13, 2019 at 5:01 PM swfiua at gmail.com wrote: > >> Hi, >> >> I just wanted to provide some background on the recent flurry of fixes to >> table.py and the history behind the code. >> >> See attached pdf. >> >> There are 3 main themes to the changes: >> >> * better automatic setting of the font size >> * change how horizontal padding around cell text is calculated >> * add ability to specify cell edge colours >> >> John >> _______________________________________________ >> 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 > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From swfiua at gmail.com Thu Jun 13 13:35:58 2019 From: swfiua at gmail.com (swfiua at gmail.com) Date: Thu, 13 Jun 2019 13:35:58 -0400 Subject: [Matplotlib-devel] Pull requests for table.py In-Reply-To: References: Message-ID: On Thu, Jun 13, 2019 at 11:42 AM Antony Lee wrote: > Hi John, > > Thanks for your writeup. It provides an interesting historical view on > one of the oldest parts of the Matplotlib codebase, which is always nice > read about. > > It is great that you intend to work again on table.py > I made no commitment to work on this again in the future ;) > (which was mostly abandoned by the other core devs), but I am not sure to > what extent the new API you propose has been stabilized, or whether you are > still experimenting with it. There are also other issues with the API > design (e.g. https://github.com/matplotlib/matplotlib/issues/12931) that > you may, perhaps, want to revisit? > There are four (now 5) pull requests with various API changes / bug fixes for consideration -- just created one of issue 12931 Those requests themselves resulted in other discussion about API changes (eg should visible_edges change its name to border?) -- so some on-going experimentation. Some of the bugs are such that they can't really be fixed without impacting the API. There is a fair bit to discuss here -- most of the feedback that I have received so far has been about cosmetic stuff with very little comment on the substance of the changes. >From my point of view I am pretty much done experimenting at this point. > As you may have noticed, making backwards incompatible changes to > Matplotlib is a bit of an onerous process (due to the deprecation process, > the baseline images problem, etc.). > Indeed. Which is a big reason these problems have languished so long. Just because the process is onerous, doesn't mean it shouldn't be done. The baseline_images problem feels like the tail wagging the dog. > Given that table.py is fairly self-contained, perhaps you may want to > consider moving it to its own separate package? > > i.e. something published separately on PyPI (let us know if you need any > help for that), so that one would do (for example) > > from mpltable import table > table(...) > > > This way you can play with the API in whatever way you want, and we could > just point to your package as the "new, more modern" way to make tables > with Matplotlib, and possibly import it back to the main repo as a single > PR once everything is stabilized. > Whilst I can see the attraction with this approach, I am not really keen on it. Based on my experiences so far trying to help out here, there is no guarantee that the new table would ever make it into the code and that would leave me with an increasing maintenance burden of pulling on-going changes to the code, whilst leaving matplotlib with a buggy and ugly table. There are pros and cons with one big fix v a bunch of smaller ones. I lean towards the several smaller fix approach eg issue 12931 should probably be done as a standalone request, making it easier to back out later if it becomes necessary. John > > Antony > > On Thu, Jun 13, 2019 at 5:01 PM swfiua at gmail.com wrote: > >> Hi, >> >> I just wanted to provide some background on the recent flurry of fixes to >> table.py and the history behind the code. >> >> See attached pdf. >> >> There are 3 main themes to the changes: >> >> * better automatic setting of the font size >> * change how horizontal padding around cell text is calculated >> * add ability to specify cell edge colours >> >> John >> _______________________________________________ >> 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 swfiua at gmail.com Thu Jun 13 17:34:43 2019 From: swfiua at gmail.com (swfiua at gmail.com) Date: Thu, 13 Jun 2019 17:34:43 -0400 Subject: [Matplotlib-devel] Pull requests for table.py In-Reply-To: References: Message-ID: So, thinking cap on... This separate mpltable package does have some distinct advantages in terms of making any switch, for everyone I think. When you are ready to switch make mpltable a dependency and import from that. Or use it interactively, just import the mpltable.table then I think it is just axes.add_table(table) you have to use. The problem (?) with tables is everyone has an opinion how they should look, so things can get out of control, quickly. Exporting that into a side discussion is a good idea. Which is part of the problem with the current flurry of changes: there are a lot of variants and options to consider. It would be very helpful to have the freedom to worry less about whose code we break. It solves another problem, which is where to document some of the history, which is another sideshoot. And explain the bits of the code I now think I understand. That would be an awesome way to go forward. Thanks for the understanding. Johnny On Thu, Jun 13, 2019 at 12:04 PM Thomas Caswell wrote: > John, > > I will also add that if you want to got the stand-alone package route we > can put the repo under the Matplotlib org and give you full control of it. > > Tom > > On Thu, Jun 13, 2019 at 11:51 AM Antony Lee > wrote: > >> Hi John, >> >> Thanks for your writeup. It provides an interesting historical view on >> one of the oldest parts of the Matplotlib codebase, which is always nice >> read about. >> >> It is great that you intend to work again on table.py (which was mostly >> abandoned by the other core devs), but I am not sure to what extent the new >> API you propose has been stabilized, or whether you are still experimenting >> with it. There are also other issues with the API design (e.g. >> https://github.com/matplotlib/matplotlib/issues/12931) that you may, >> perhaps, want to revisit? >> >> As you may have noticed, making backwards incompatible changes to >> Matplotlib is a bit of an onerous process (due to the deprecation process, >> the baseline images problem, etc.). Given that table.py is fairly >> self-contained, perhaps you may want to consider moving it to its own >> separate package? i.e. something published separately on PyPI (let us know >> if you need any help for that), so that one would do (for example) >> >> from mpltable import table >> table(...) >> >> >> This way you can play with the API in whatever way you want, and we could >> just point to your package as the "new, more modern" way to make tables >> with Matplotlib, and possibly import it back to the main repo as a single >> PR once everything is stabilized. >> >> Antony >> >> On Thu, Jun 13, 2019 at 5:01 PM swfiua at gmail.com >> wrote: >> >>> Hi, >>> >>> I just wanted to provide some background on the recent flurry of fixes >>> to table.py and the history behind the code. >>> >>> See attached pdf. >>> >>> There are 3 main themes to the changes: >>> >>> * better automatic setting of the font size >>> * change how horizontal padding around cell text is calculated >>> * add ability to specify cell edge colours >>> >>> John >>> _______________________________________________ >>> 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 >> > > > -- > Thomas Caswell > tcaswell at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstansby at gmail.com Tue Jun 25 13:44:37 2019 From: dstansby at gmail.com (David Stansby) Date: Tue, 25 Jun 2019 18:44:37 +0100 Subject: [Matplotlib-devel] Using towncrier to generate changelogs Message-ID: Dear all, I am proposing to change up how Matplotlib's API changes/what's new pages are generated, in particular moving to using towncrier to add more automation to the process. This is motivated by the crazy amount of time it took me to combine all the API change and what's new fragments into a coherent page for the 3.1.0 release. The PR to change this process is here: https://github.com/matplotlib/matplotlib/pull/14589 The new process would be - When a new feature or api change or code removal is implemented, add a changelog file to the *changelog/* folder - The changelog file should be named ..rst, and should contain a single sentence or paragraph describing the change. is the type of change, ie. api_change, new_feature or removal - towncrier can then automatically collate these fragments into a single .rst page, which can be manually edited if needed before releasing I think this will significnatly reduce the burden of producing what's new pages each release, without adding any extra burden on those writing the what's new entries. Please take a look at the PR and leave comments/questions/suggestions! In particular, feedback on what "types" of changelog entry to include would be very welcome. All the best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Sun Jun 30 12:36:45 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Sun, 30 Jun 2019 12:36:45 -0400 Subject: [Matplotlib-devel] Welcome to Martin Renou Message-ID: Folks, Please welcome Martin Renou (@martinRenou on github) to the team! He is working on ipympl (aka %matplotlib widget). Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: