Mailman 3 October 2016 - Matplotlib-devel

[matplotlib-devel] The GitHub labels
by Thomas Caswell Oct. 31, 2016

Oct. 31, 2016

Forward of Nelle's orginal email to the python.org list (which should have the graph Paul is talking about attached). Tom ---------- Forwarded message --------- From: Nelle Varoquaux <nelle.varoquaux(a)gmail.com> Date: Sat, Oct 29, 2016 at 5:46 PM Subject: [matplotlib-devel] The GitHub labels To: matplotlib-devel(a)lists.sourceforge.net < matplotlib-devel(a)lists.sourceforge.net> Hi team, We've been discussing at several occasions of cleaning up our GitHub labels, and merging some. In order to guide the discussion of which labels to keep and to move, I've analysed a bit what where the labels we were using. Attached is a plot of the number of issues (including PRs) open and closed for each labels. Maybe we have too many labels? Most of them don't seem actively used. For example, py3k seem to be used 4 times, only on closed tickets/PR. I've done a similar analysis on scikit-image, scikit-learn and ipython. Some labels seem to be consistently used quite highly across all projects: the 3 difficulty levels, bug, ENH, DOC. I'm playing a bit with the github API this afternoon, so if any other statistics is useful, just let me know. Cheers, N ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

1 0

Re: [Matplotlib-devel] [matplotlib-devel] The GitHub labels
by Paul Hobson Oct. 30, 2016

Oct. 30, 2016

Nelle, Thanks for pulling this together. You sent it to this old source forge list and not the new python.org list, so I've fixed that with this reply. Honestly, the graph makes to problems not seem as bad as I thought it was. I feel like most of the low-count tags like the MEPs and backends should stay. But certainly things like "low-hanging" fruit and "Difficulty: Easy" could be merged. -paul On Sat, Oct 29, 2016 at 2:45 PM, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> wrote: > Hi team, > > We've been discussing at several occasions of cleaning up our GitHub > labels, and merging some. In order to guide the discussion of which > labels to keep and to move, I've analysed a bit what where the labels > we were using. Attached is a plot of the number of issues (including > PRs) open and closed for each labels. > Maybe we have too many labels? Most of them don't seem actively used. > For example, py3k seem to be used 4 times, only on closed tickets/PR. > > I've done a similar analysis on scikit-image, scikit-learn and > ipython. Some labels seem to be consistently used quite highly across > all projects: the 3 difficulty levels, bug, ENH, DOC. > > I'm playing a bit with the github API this afternoon, so if any other > statistics is useful, just let me know. > > Cheers, > N > > ------------------------------------------------------------ > ------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >

1 0

building from source with PyPy
by Matti Picus Oct. 19, 2016

Oct. 19, 2016

Hi. I am a PyPy dev. Today I tried building wxPython Phoenix using PyPy, and would like to share my experience :). It took me a while to find the github repo, the wiki and web site do not seem to mention it AFAICT. In fact, the buildbot instructions here https://wiki.wxpython.org/ProjectPhoenix/BuildbotSlave tricked me into thinking that SVN was stil the preferred method of source control for the project. But once I found the github repo https://github.com/wxWidgets/Phoenix everything became easier. Since I am using a dev version of PyPy (not packaged by the Debian maintainer, rather the nightly HEAD), I needed to roll my own pypy-config based on the python27-config script. Of course, the build immediately crashed since our C-API compatibility is not yet good enough. We seem to have some badly declared function signatures that do not match CPython, I will be fixing these over the next few weeks, and may need to submit patches or fixes for too heavy-duty use of c pointers that I cannot fix on the PyPy side of things. I would love to get the wxPython toolkit working under PyPY, so I hope there are not too many patches needed. FWIW, we did try to use CFFI instead of the C-API a few years back during a Google Summer of Code, the results are languishing on https://bitbucket.org/waedt/wxpython_cffi. So thanks for wxPython, and stay tuned, hopefully I can make some progress here Matti

2 2

Vega color names
by Nelle Varoquaux Oct. 18, 2016

Oct. 18, 2016

Hello everyone, Nathan just proposed names for the new vega colors: https://github.com/matplotlib/matplotlib/issues/7248 As Antony mentioned, getting the names right is quite important as this is probably going to be the default for the next 10 years. Cheers, N

2 1

Access to mpl's google analytics
by Thomas Caswell Oct. 17, 2016

Oct. 17, 2016

Folks, If you have commit rights and would like access to the GA for matplotlib.org send me a gmail account. Tom

1 0

Markup text
by Nicolas P. Rougier Oct. 17, 2016

Oct. 17, 2016

Based on the example rainbow_text.py in the gallery, I've tried to implement a simple markup extension to the text directive (see code below). It's far from complete but I would like to know if there's any interest in that and if it's worth making a MEP (and if yes, could someone remind me the procedure for doing that ?). The idea is to be able to use pango-like markup text for quick/small changes of the text: Examples: "Hello world!" "Hello world!" "Hello world" Currently, the implementation only works for non-rotated text. Nicolas

4 5

Deleting the color_overhaul branch
by Elliott Sales de Andrade Oct. 16, 2016

Oct. 16, 2016

Hello, I've been looking over all PRs to the color_overhaul branch. It appears that half the commits were merged into master [1], and consequentially 1.5.0. The remaining commits were cherry-picked to master as well. I have re-milestoned all those PRs (and several dependent issues) to v1.5.0 now. There is one remaining open PR #4290 [2]. Since GitHub now supports changing the base branch, I have re-targeted this PR to master. Can the color_overhaul branch now be deleted? [1] https://github.com/matplotlib/matplotlib/commit/0f940b10d1982ca39642524d3c1… [2] https://github.com/matplotlib/matplotlib/pull/4290 -- Elliott

2 2

Removing boxplot's complexity (mpl v3.0?)
by Paul Hobson Oct. 14, 2016

Oct. 14, 2016

Now that the distinction between Axes.bxp (drawer) and Axes.boxplot() are well established, I think it's time that we start thinking about how the high-level, easy-to-use, sane-default API of Axes.boxplot should look. TL;DR version: I am proposing that we: * dramatically simplify Axes.boxplot * move a small portion of that complexity to Axes.bxp * move most of that complexity into user-defined functions by way of ... * adding the option to pass a custom stats function to Axes.boxplot * (optional) make very minor changes to cbook.boxplot_stats to allow users to specify pre- and post-calculation transformations (e.g., np.log, np.exp) I am committing to: * implement all proposed changes * create user docs outlining the new behavior with practical and complete examples * maintaining these changes for the foreseeable future. Full version: I'm willing and quick to admit that boxplot's complexity is born from my needs that I was trying to address several years ago. I'm sorry for that. However, I've learned a lot since I first started us down this path and I think I see a way to get out of the woods. Currently, boxplot's signature looks like this: def boxplot(self, x, notch=None, sym=None, vert=None, whis=None, positions=None, widths=None, patch_artist=None, bootstrap=None, usermedians=None, conf_intervals=None, meanline=None, showmeans=None, showcaps=None, showbox=None, showfliers=None, boxprops=None, labels=None, flierprops=None, medianprops=None, meanprops=None, capprops=None, whiskerprops=None, manage_xticks=True, autorange=False, zorder=None): I think I can get it down to this: def boxplot(self, data, label=None, vert=False, whis=None, positions=None, widths=None, patch_artist=None, shownotch=False, showmeans=None, showcaps=None, showbox=None, showfliers=None, boxprops=None, flierprops=None, medianprops=None, meanprops=None, capprops=None, whiskerprops=None, manage_xticks=True, zorder=None, statfxn=None, **stafxn_kwargs): It doesn't look like much, but dropping ``usermedians`` and ``conf_intervals``, alone would allow us to cut 25 SLOC from boxplot that contain 9 separate if/else statements nested up to 5 levels deep with a for loop, and raise up to 2 errors. It's worth noting that these parameters are likely used by a very few users who are very advanced. Similarly, the property kwargs (e.g., ``capprops``, ``medianprop``) and the show kwargs (e.g., ``showbox``, ``showfliers``) can be passed directly to and handled solely by Axes.bxp. That would remove ~75 LOC from axes.boxplot (with some amount being moved to Axes.bxp). What would be added Axes.boxplot to replace this functionality would be a ``statfxn`` option and ``**statfxn_kwargs``. ``statfxn`` would default to ``cbook.boxplot_stats``, which is the current behavior. But users could easily pass their own function and the necessary options (e.g., ``bootstrap``) via ``**statfxn_kwargs``. The big win here is that letting users pass their own stats function to the top-level boxplot means that users of libraries like seaborn will be able to incorporate their own confidence interval estimates, data transformations, etc directly in to the boxplot. It sounds minor, but see how different boxplots of lognormal data look depending on which space you compute the stats: https://github.com/mwaskom/seaborn/issues/432#issuecomment-71501177 With that in mind, I think we could cover ~90% of the use-cases that would require a custom stats function if we allowed cbook.boxplots_stats to take pre- and post-calculation transformation functions (e.g., np.log and np.exp for the example above) All in all, I think these changes will be surprisingly minor but represent a major improvement in maintainability. If there's interest, I'd be happy to draft up the changes very shortly to make all of this a little more concrete. -Paul p.s. An even more spartan approach would be to remove the complexity from Axes.boxplot and tell advanced users that if they want to customize things, they need to compute their own stats and use Axes.bxp

2 1

encoders for animations
by Eric Firing Oct. 1, 2016

Oct. 1, 2016

For making video files the animation module presently supports ffmpeg (the default), avconv (a fork of ffmpeg), and mencoder. Does anyone use mencoder? If so, why? And would you be seriously inconvenienced or otherwise harmed if we ended our only partially successful support of mencoder as an option in the animation module? Thank you. Eric

1 0