Mailman 3 February 2018 - Matplotlib-devel

What minimum version of python3?
by Thomas Caswell March 17, 2018

March 17, 2018

These are derived from today's call: Pro 3.6: - by the time we release, 3.7 will be out so will support "two most recent python" - this gives 3 years of support on master of each python version (assuming python sticks - ordered, faster dictionaries (as implementation detail in 3.6, guaranteed in 3.7) - guaranteed ordered kwargs / class definitions (do precedence of conflicting kwaargs) - fstrings - fspath / pathlib protocol Con 3.6: - feels a bit agressive as 3.7 is not out yet - might get ahead of some LTS releases - but older version of Matplotlib will still work - user-space environments go along way to fixing this - conda - https://www.digitalocean.com/community/tutorials/how-to-install-python-3-an… - ubuntu 18.04 is planned to be py3.6 by default Pro 3.5: - more conservative approach - pypy3 support (but they will support 3.6 eventually) The consensus on the call and on gitter seems to be for 3.6 as the minimum. Tom

5 8

Documentation
by Matt Arcidy March 16, 2018

March 16, 2018

Hi All, Please forgive the presumption of pulling this topic out of from the meeting thread especially as this is also in a self-introduction email. I want to help with the documentation effort. I read Tom's article in numfocus and the desired skillset rang true. I have 10ish years experience writing tech docs, a few 100+ pages. I write creatively, and I am still somewhat new to matplotlib. I am happy to work in any capacity, though i am most interested in cranking out the first draft of the book. I have looked into the available documentation over the past month+ so I could come with understanding and ideas, some of which I hope are actually good. Both the meeting thread and Tom requested ideas for reorganizing the tutorials and examples as a place to start, so I'll throw one out: explicit definition of an audience, something to which all the documentation can adhere. Right now the tutorials are leveled as beginner, intermediate, and expert, which is great, but it's not clear what that means. Explicitly defining the required skill sets, while not perfect, will allow sorting of concepts and people into each bin. As an example, (please excuse the contrivence): Laura - Sophomore in college - dead set on being a data scientist - 2 programming classes in python - never used any kind of CAD software ever (i.e. does not have any concept of a plot beyond a line on graph paper) Xian - 1 week away from Zoology PhD dissertation, under a deadline - Has used R and Matplotlib to create very basic plots for papers - Wants to create a plot with species heart size over adult weight, with the marker being a jpg of the species' actual heart, beating at the actual species' heart rate on the plot. Ayah - Post Doc or professional - 10+ years of plotting experience using various packages but not matplotlib - has funding to contribute significant functionality, but needs to get up to speed on everything now Obviously this is just beginner, intermediate, expert, but they can be explicitly targeted/taught based on their skill level. Laura needs hand-holding, Xian needs a great API reference, Ayah needs a mosaic of everything and a good architecture map. In the same vein as above, learning paths through the tutorial documents. There are some separable plotting skills, like visually designing the plot, animation, application development, matplotlib development...etc. Each skill could have beginner/intermediate/expert level tutorials which progress naturally, creating a learning tract for each skill. Skills can be stacked to flow into specific roles. Looking at this from outside, the best part about this project is all the information is already there. I have more ideas to dump on you, but I'll postpone until I have a better understanding of where I can fit. Thanks!

7 18

[ANN] Matplotlib v2.2.0rc1
by Thomas Caswell Feb. 14, 2018

Feb. 14, 2018

Folks, We are happy to release Matplotlib v2.2.0rc1! This is a feature release which includes new functionality (along with many bug-fixes). One of the hi-lights of this release is a constrained layout manager, please see https://matplotlib.org/devdocs/users/whats_new.html for details. API changes are at https://matplotlib.org/devdocs/api/api_changes.html The rc can be installed via pip pip install --pre matplotlib or via conda from conda-forge conda install -c conda-forge/label/rc matplotlib -c conda-forge The goal is to do 2.2.0 final around Mar. 2, please test these out and report bugs this week and next! mpl2.2 will be the last feature release in the Matplotlib 2.x series and the last feature release of Matplotlib to support python 2.7 and intend to provide bug fixes to 2.2 until 2020. We are looking for someone to take the lead on maintaining the 2.2.x branch, if you are interested please reach out! The next feature release after 2.2 will be 3.0 scheduled for July-August 2018. Thank you everyone (100+) who contributed to this release! Tom

1 0

2018-02-12 call notes
by Thomas Caswell Feb. 12, 2018

Feb. 12, 2018

Me, Eric, Ryan Seems to be calm before the storm of 2.2rc1 issues. Talked about which version of python 3 to use (follow up email coming) Briefly discussed type annotations. Discussed possible Matplotlib 4 redesign options. Tom

1 0

[ANN] Matplotlib v2.2.0rc1 tagged
by Thomas Caswell Feb. 12, 2018

Feb. 12, 2018

Folks, We have tagged RC1 for 2.2! We have many bug-fixes, performance improvements and new features in this release! 2.2 will be a 'long-term support' release and we will do bug-fix release on it until 2020. Aiming for a final release in 2 weeks (Mar 2). We'll sort out over the next week if we want to do an RC2 or not. I have created a v2.2.x branch for managing the 2.2.0 release work and the 2.2.x series going forward. With this tag, the master branch is python 3 only. There will be a follow up email to discuss if we are py3.5+ or py3.6+, for now lets stay with 3.5+. As part of this I have cleaned out the upstream branches and merged them all up: - master: mpl3.0 work and new features, python3 only - v2.2.x : v2.2.x series work. Only bug-fixes and documentation updates, python 2.7, 3.4+ - v2.1.2-doc : documentation changes only to rebuild the current stable docs. When 2.2.0 is out this will be replaced by v2.2.0-doc Thanks to everyone who worked on this release! Tom

1 0

Units discussion...
by Jody Klymak Feb. 9, 2018

Feb. 9, 2018

Hi all, To carry on the gitter discussion about unit handling, hopefully to lead to a more stringent documentation and implimentation…. In response to @anntzer I thought about the units support a bit - it seems that rather than a transform, a more straightforward approach is to have the converter map to float arrays in a unique way. This float mapping would be completely analogous to `date2num` in `dates`, in that it doesn’t change and is perfectly invertible without matplotlib ever knowing about the unit information, though the axis could store it for the the tick locators and formatters. It would also have an inverse that would supply data back to the user in unit-aware data (though not necessarily in the unit that the user supplied. e.g. if they supply 8*in, the and the converter converts everything to meter floats, then the returned unitized inverse would be 0.203*m, or whatever convention the converter wants to supply.). User “unit” control, i.e. making the plot in inches instead of m, would be accomplished with ticks locators and formatters. Matplotlib would never directly convert between cm and inches (any more than it converts from days to hours for dates), the downstream-supplied tick formatter and labeller would do it. Each axis would only get one converter, set by the first call to the axis. Subsequent calls to the axis would pass all data (including bare floats) to the converter. If the converter wants to pass bare floats then it can do so. If it wants to accept other data types then it can do so. It should be possible for the user to clear or set the converter, but then they should know what they are doing and why. Whats missing? I don’t think this is wildly different than what we have, but maybe a bit more clear. Cheers, Jody

7 28

Re: [Matplotlib-devel] Matplotlib-devel Digest, Vol 31, Issue 18
by Matti Picus Feb. 8, 2018

Feb. 8, 2018

There is this "Matplotlib Enhancement Proposals" https://matplotlib.org/devel/MEP/index.html which I guess starts as a pull request with a new MEP, and discussion continues on github under the pull request? Matti On 2/8/2018 3:15 PM, matplotlib-devel-request(a)python.org wrote: > Let's find a better venue for this discussion that lends itself for > everyone to join in*together*, synchronously, and in a form where we're > not guessing at tone.

1 0

new maintainer
by Thomas Caswell Feb. 7, 2018

Feb. 7, 2018

Folks, Please welcome Dietmar Schwertberger to the team. He is going to take the lead on the Wx backend. Tom

3 2

New maintainer
by Thomas Caswell Feb. 6, 2018

Feb. 6, 2018

Folks, Please welcome Tim Hoffmann (@timhoffm) to the team! Tom PS Tim, sorry for being slow getting this out.

4 3

Call notes 29 Jan
by Jody Klymak Feb. 1, 2018

Feb. 1, 2018

Hi all, Call notes from Monday’s call. Cheers, Jody On call: Thomas, Eric, Ryan, Jody, Antony (later half) ## Documentation Thomas reported that there is a fund for a mini-workshop to scope out documentation changes. Plan was to use that to write a proposal to fund a book. - Eric expressed some reservations about a book, given the state of flux some parts of Matplotlib are in. - Jody noted that beyond the book, a shorter “getting started” guide on the webpage would still be desirable: ACTION: Jody to co-ordinate a couple of outline documents that could start outlining both of these projects before any meeting. There was also some discussion of online documentation technology: - Notebooks (via nbsphinx: https://nbsphinx.readthedocs.io) - hard to make PRs with. Diffs are a mess in GitHub. - Can’t use emacs (easily) - RST-based, with plot directive: - python authoring less than desirable - Sphinx-gallery based: - rst authoring less than desirable - sphinx gallery has very restricted ordering methods (file size and alphabetical) ## Release 2.2 Various Release-Critical PRs were looked at. -- Jody Klymak http://web.uvic.ca/~jklymak/

6 12