From Nicolas.Rougier at inria.fr  Mon Oct 10 01:06:25 2016
From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier)
Date: Mon, 10 Oct 2016 07:06:25 +0200
Subject: [Matplotlib-devel] Markup text
Message-ID: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>



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 <b>world</b>!"
"Hello <span color=blue>world</span>!"
"Hello <span family=serif size=x-small>world</span>"


Currently, the implementation only works for non-rotated text.


Nicolas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: markup.py
Type: text/x-python-script
Size: 4388 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161010/79d05984/attachment.bin>

From pmhobson at gmail.com  Wed Oct 12 16:32:46 2016
From: pmhobson at gmail.com (Paul Hobson)
Date: Wed, 12 Oct 2016 13:32:46 -0700
Subject: [Matplotlib-devel] Removing boxplot's complexity (mpl v3.0?)
Message-ID: <CADT3MEAGUQ-qV13SUSgEyjsn5vh7e2n96Qb-zrjqv=yN3zeEEw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161012/ff20207e/attachment.html>

From tcaswell at gmail.com  Fri Oct 14 09:05:36 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 14 Oct 2016 13:05:36 +0000
Subject: [Matplotlib-devel] Removing boxplot's complexity (mpl v3.0?)
In-Reply-To: <CADT3MEAGUQ-qV13SUSgEyjsn5vh7e2n96Qb-zrjqv=yN3zeEEw@mail.gmail.com>
References: <CADT3MEAGUQ-qV13SUSgEyjsn5vh7e2n96Qb-zrjqv=yN3zeEEw@mail.gmail.com>
Message-ID: <CAA48SF-9SC=LAxg8Un0jg6EL72thxM0TXQsoBWMOu8NuLh0onA@mail.gmail.com>

This sounds reasonable, but I think we can do this over the course of 3
minor releases (1 release warning kwargs are going away, 1 raising custom
error, then gone) given the limited scope of the API change.

Could you also put the text of this email in a MEP  (
https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP )?


Tom


On Wed, Oct 12, 2016 at 4:33 PM Paul Hobson <pmhobson at gmail.com> wrote:

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
_______________________________________________
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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161014/fa3f7ffe/attachment.html>

From tcaswell at gmail.com  Fri Oct 14 10:06:39 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 14 Oct 2016 14:06:39 +0000
Subject: [Matplotlib-devel] Markup text
In-Reply-To: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
References: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
Message-ID: <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>

Nicolas,

Put an a PR adding a file to
https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP is the
current MEP procedure.

Tom

On Mon, Oct 10, 2016 at 1:09 AM Nicolas P. Rougier <Nicolas.Rougier at inria.fr>
wrote:

>
>
> 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 <b>world</b>!"
> "Hello <span color=blue>world</span>!"
> "Hello <span family=serif size=x-small>world</span>"
>
>
> Currently, the implementation only works for non-rotated text.
>
>
> Nicolas
>
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161014/1669fbbc/attachment.html>

From Nicolas.Rougier at inria.fr  Fri Oct 14 13:17:47 2016
From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier)
Date: Fri, 14 Oct 2016 19:17:47 +0200
Subject: [Matplotlib-devel] Markup text
In-Reply-To: <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>
References: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
 <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>
Message-ID: <A8EDA6F1-8D42-48FF-9FA2-47AA98638FD8@inria.fr>

Thanks Thomas.

Just realized I've an old MEP (MEP28 https://github.com/matplotlib/matplotlib/pull/4384), should I create a MEP29 instead ? How do I know if someone else is already working on a different MEP 29 ?


Nicolas



> On 14 Oct 2016, at 16:06, Thomas Caswell <tcaswell at gmail.com> wrote:
> 
> Nicolas,
> 
> Put an a PR adding a file to https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP is the current MEP procedure.
> 
> Tom
> 
> On Mon, Oct 10, 2016 at 1:09 AM Nicolas P. Rougier <Nicolas.Rougier at inria.fr> wrote:
> 
> 
> 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 <b>world</b>!"
> "Hello <span color=blue>world</span>!"
> "Hello <span family=serif size=x-small>world</span>"
> 
> 
> Currently, the implementation only works for non-rotated text.
> 
> 
> Nicolas
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel


From juichenieder-nabb at yahoo.co.uk  Fri Oct 14 15:05:13 2016
From: juichenieder-nabb at yahoo.co.uk (OceanWolf)
Date: Fri, 14 Oct 2016 19:05:13 +0000 (UTC)
Subject: [Matplotlib-devel] Markup text
In-Reply-To: <A8EDA6F1-8D42-48FF-9FA2-47AA98638FD8@inria.fr>
References: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
 <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>
 <A8EDA6F1-8D42-48FF-9FA2-47AA98638FD8@inria.fr>
Message-ID: <549546985.1398417.1476471913251@mail.yahoo.com>

Good question, the only answer we have right now revolves around changing the MEP number at merge time into trunk.? If changing the MEP number exists as the only thing left to do, then it will get merged straight away, easy, so no having to come back to change it a 2nd time.
Best,Oceanwolf

      From: Nicolas P. Rougier <Nicolas.Rougier at inria.fr>
 To: Thomas Caswell <tcaswell at gmail.com> 
Cc: matplotlib development list <matplotlib-devel at python.org>
 Sent: Friday, 14 October 2016, 19:17
 Subject: Re: [Matplotlib-devel] Markup text
   
Thanks Thomas.

Just realized I've an old MEP (MEP28 https://github.com/matplotlib/matplotlib/pull/4384), should I create a MEP29 instead ? How do I know if someone else is already working on a different MEP 29 ?


Nicolas



> On 14 Oct 2016, at 16:06, Thomas Caswell <tcaswell at gmail.com> wrote:
> 
> Nicolas,
> 
> Put an a PR adding a file to https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP is the current MEP procedure.
> 
> Tom
> 
> On Mon, Oct 10, 2016 at 1:09 AM Nicolas P. Rougier <Nicolas.Rougier at inria.fr> wrote:
> 
> 
> 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 <b>world</b>!"
> "Hello <span color=blue>world</span>!"
> "Hello <span family=serif size=x-small>world</span>"
> 
> 
> Currently, the implementation only works for non-rotated text.
> 
> 
> Nicolas
> 
> 
> _______________________________________________
> 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161014/84c44d14/attachment.html>

From antony.lee at berkeley.edu  Fri Oct 14 15:57:21 2016
From: antony.lee at berkeley.edu (Antony Lee)
Date: Fri, 14 Oct 2016 12:57:21 -0700
Subject: [Matplotlib-devel] Markup text
In-Reply-To: <549546985.1398417.1476471913251@mail.yahoo.com>
References: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
 <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>
 <A8EDA6F1-8D42-48FF-9FA2-47AA98638FD8@inria.fr>
 <549546985.1398417.1476471913251@mail.yahoo.com>
Message-ID: <CAGRr6BEycr_ChzH_f5ifPe-JZwsD4zHFVmBP1=196sTxiZibqw@mail.gmail.com>

Wouldn't it make more sense to implement this as improvements to mathtext?
instead of

"Hello <b>world</b>!"
"Hello <span color=blue>world</span>!"
"Hello <span family=serif size=x-small>world</span>"


have

r"$\text{Hello \textbf{world}}$"

r"$\text{Hello \textcolor{blue}{world}}$"

r"$\text{Hello \textsf{\small world}}$"


You'll be able to have a better layout this way too (reusing the mathtext
layout engine).
One could have some helper if "$\text{}$" is too much to type (but TBH you
immediately gain back on the fact that you don't need closing tags...).

Antony

2016-10-14 12:05 GMT-07:00 OceanWolf via Matplotlib-devel <
matplotlib-devel at python.org>:

> Good question, the only answer we have right now revolves around changing
> the MEP number at merge time into trunk.  If changing the MEP number exists
> as the only thing left to do, then it will get merged straight away, easy,
> so no having to come back to change it a 2nd time.
> Best,
> Oceanwolf
>
> ------------------------------
> *From:* Nicolas P. Rougier <Nicolas.Rougier at inria.fr>
> *To:* Thomas Caswell <tcaswell at gmail.com>
> *Cc:* matplotlib development list <matplotlib-devel at python.org>
> *Sent:* Friday, 14 October 2016, 19:17
> *Subject:* Re: [Matplotlib-devel] Markup text
>
> Thanks Thomas.
>
> Just realized I've an old MEP (MEP28 https://github.com/matplotlib/
> matplotlib/pull/4384), should I create a MEP29 instead ? How do I know if
> someone else is already working on a different MEP 29 ?
>
>
> Nicolas
>
>
>
> > On 14 Oct 2016, at 16:06, Thomas Caswell <tcaswell at gmail.com> wrote:
> >
> > Nicolas,
> >
> > Put an a PR adding a file to https://github.com/matplotlib/
> matplotlib/tree/master/doc/devel/MEP is the current MEP procedure.
> >
> > Tom
> >
> > On Mon, Oct 10, 2016 at 1:09 AM Nicolas P. Rougier <
> Nicolas.Rougier at inria.fr> wrote:
> >
> >
> > 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 <b>world</b>!"
> > "Hello <span color=blue>world</span>!"
> > "Hello <span family=serif size=x-small>world</span>"
> >
> >
> > Currently, the implementation only works for non-rotated text.
> >
> >
> > Nicolas
> >
> >
> > _______________________________________________
> > 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161014/43f4c093/attachment-0001.html>

From quantum.analyst at gmail.com  Sat Oct 15 22:48:38 2016
From: quantum.analyst at gmail.com (Elliott Sales de Andrade)
Date: Sat, 15 Oct 2016 22:48:38 -0400
Subject: [Matplotlib-devel] Deleting the color_overhaul branch
Message-ID: <CAJP_izcm48vKcWLuF4Lwt3PPrPaLjBosGQ42eWn3buG6-Vk2zg@mail.gmail.com>

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/0f940b10d1982ca39642524d3c19c8cde9b9838a
[2] https://github.com/matplotlib/matplotlib/pull/4290

-- 
Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161015/de53aaf8/attachment.html>

From tcaswell at gmail.com  Sat Oct 15 22:58:37 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sun, 16 Oct 2016 02:58:37 +0000
Subject: [Matplotlib-devel] Deleting the color_overhaul branch
In-Reply-To: <CAJP_izcm48vKcWLuF4Lwt3PPrPaLjBosGQ42eWn3buG6-Vk2zg@mail.gmail.com>
References: <CAJP_izcm48vKcWLuF4Lwt3PPrPaLjBosGQ42eWn3buG6-Vk2zg@mail.gmail.com>
Message-ID: <CAA48SF_UUcb3AgC7-h9fxCMp_WgioL3wafZv-=bKkGPNbZUtiQ@mail.gmail.com>

Yes.

Thanks for doing the due diligence on this!

Tom

On Sat, Oct 15, 2016, 22:48 Elliott Sales de Andrade <
quantum.analyst at gmail.com> wrote:

> 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/0f940b10d1982ca39642524d3c19c8cde9b9838a
> [2] https://github.com/matplotlib/matplotlib/pull/4290
>
> --
> Elliott
> _______________________________________________
> 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161016/6b524ee9/attachment.html>

From quantum.analyst at gmail.com  Sat Oct 15 23:16:01 2016
From: quantum.analyst at gmail.com (Elliott Sales de Andrade)
Date: Sat, 15 Oct 2016 23:16:01 -0400
Subject: [Matplotlib-devel] Deleting the color_overhaul branch
In-Reply-To: <CAA48SF_UUcb3AgC7-h9fxCMp_WgioL3wafZv-=bKkGPNbZUtiQ@mail.gmail.com>
References: <CAJP_izcm48vKcWLuF4Lwt3PPrPaLjBosGQ42eWn3buG6-Vk2zg@mail.gmail.com>
 <CAA48SF_UUcb3AgC7-h9fxCMp_WgioL3wafZv-=bKkGPNbZUtiQ@mail.gmail.com>
Message-ID: <CAJP_izfy6pqHoQscfDVACpXy6RDNW4vGV8+i+aTNpa440xrhTg@mail.gmail.com>

OK, it is now gone.

Also, I've struck out all the mentions of backports to that branch.

On 15 October 2016 at 22:58, Thomas Caswell <tcaswell at gmail.com> wrote:

> Yes.
>
> Thanks for doing the due diligence on this!
>
> Tom
>
> On Sat, Oct 15, 2016, 22:48 Elliott Sales de Andrade <
> quantum.analyst at gmail.com> wrote:
>
>> 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/
>> 0f940b10d1982ca39642524d3c19c8cde9b9838a
>> [2] https://github.com/matplotlib/matplotlib/pull/4290
>>
>> --
>> Elliott
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>


-- 
Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161015/80389526/attachment.html>

From Nicolas.Rougier at inria.fr  Mon Oct 17 03:46:05 2016
From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier)
Date: Mon, 17 Oct 2016 09:46:05 +0200
Subject: [Matplotlib-devel] Markup text
In-Reply-To: <549546985.1398417.1476471913251@mail.yahoo.com>
References: <0201348F-804C-462D-9EDA-903C7CFF2A9E@inria.fr>
 <CAA48SF8iDq6-5NkH1ROHdEE0TDba7s_6vPY9VjSJB47f80JsEg@mail.gmail.com>
 <A8EDA6F1-8D42-48FF-9FA2-47AA98638FD8@inria.fr>
 <549546985.1398417.1476471913251@mail.yahoo.com>
Message-ID: <67AB3941-55C4-49D5-80E0-5D005061924A@inria.fr>


Done, just opened: https://github.com/matplotlib/matplotlib/pull/7291


Nicolas

> On 14 Oct 2016, at 21:05, OceanWolf <juichenieder-nabb at yahoo.co.uk> wrote:
> 
> Good question, the only answer we have right now revolves around changing the MEP number at merge time into trunk.  If changing the MEP number exists as the only thing left to do, then it will get merged straight away, easy, so no having to come back to change it a 2nd time.
> Best,
> Oceanwolf
> 
> From: Nicolas P. Rougier <Nicolas.Rougier at inria.fr>
> To: Thomas Caswell <tcaswell at gmail.com> 
> Cc: matplotlib development list <matplotlib-devel at python.org>
> Sent: Friday, 14 October 2016, 19:17
> Subject: Re: [Matplotlib-devel] Markup text
> 
> Thanks Thomas.
> 
> Just realized I've an old MEP (MEP28 https://github.com/matplotlib/matplotlib/pull/4384), should I create a MEP29 instead ? How do I know if someone else is already working on a different MEP 29 ?
> 
> 
> Nicolas
> 
> 
> 
> > On 14 Oct 2016, at 16:06, Thomas Caswell <tcaswell at gmail.com> wrote:
> > 
> > Nicolas,
> > 
> > Put an a PR adding a file to https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP is the current MEP procedure.
> > 
> > Tom
> > 
> > On Mon, Oct 10, 2016 at 1:09 AM Nicolas P. Rougier <Nicolas.Rougier at inria.fr> wrote:
> > 
> > 
> > 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 <b>world</b>!"
> > "Hello <span color=blue>world</span>!"
> > "Hello <span family=serif size=x-small>world</span>"
> > 
> > 
> > Currently, the implementation only works for non-rotated text.
> > 
> > 
> > Nicolas
> > 
> > 
> > _______________________________________________
> > 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  Mon Oct 17 08:41:15 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 17 Oct 2016 12:41:15 +0000
Subject: [Matplotlib-devel] Access to mpl's google analytics
Message-ID: <CAA48SF9kEK8W2OEVyJZXxJ82UC986SZjtFbRuzo0_yZZVwjD5A@mail.gmail.com>

Folks,

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

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161017/46b437f1/attachment.html>

From nelle.varoquaux at gmail.com  Tue Oct 18 14:55:59 2016
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Tue, 18 Oct 2016 11:55:59 -0700
Subject: [Matplotlib-devel] Vega color names
Message-ID: <CAE-UAvRuY8GzkRqAM_4bnuqPu8ziHS7d7EwgQhRVogXMddHiHg@mail.gmail.com>

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

From isaac.gerg at gergltd.com  Tue Oct 18 15:58:21 2016
From: isaac.gerg at gergltd.com (Isaac Gerg)
Date: Tue, 18 Oct 2016 15:58:21 -0400
Subject: [Matplotlib-devel] Vega color names
In-Reply-To: <CAE-UAvRuY8GzkRqAM_4bnuqPu8ziHS7d7EwgQhRVogXMddHiHg@mail.gmail.com>
References: <CAE-UAvRuY8GzkRqAM_4bnuqPu8ziHS7d7EwgQhRVogXMddHiHg@mail.gmail.com>
Message-ID: <CADnN3yXB2QSdVMtNNP6h6XWzNYQJRtcT86snoG6iZ+q3T3FPFQ@mail.gmail.com>

Good job guys! Looks good.

On Tue, Oct 18, 2016 at 2:55 PM, Nelle Varoquaux <nelle.varoquaux at gmail.com>
wrote:

> 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
> _______________________________________________
> 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161018/81021175/attachment.html>

From matti.picus at gmail.com  Wed Oct 19 15:04:55 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 19 Oct 2016 22:04:55 +0300
Subject: [Matplotlib-devel] building from source with PyPy
Message-ID: <7772f64c-9f77-72e0-5012-6b16ae26c8ba@gmail.com>

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

From tcaswell at gmail.com  Wed Oct 19 15:14:02 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 19 Oct 2016 19:14:02 +0000
Subject: [Matplotlib-devel] building from source with PyPy
In-Reply-To: <7772f64c-9f77-72e0-5012-6b16ae26c8ba@gmail.com>
References: <7772f64c-9f77-72e0-5012-6b16ae26c8ba@gmail.com>
Message-ID: <CAA48SF_g7ETsM35ZiRZPtbaWSWcX4U58Cm1bwCY+_NxP=DOuZg@mail.gmail.com>

Matti,

I think you sent this to the wrong mailing list?  This went to
matplotlib-devel, not the wxpython list ;)

That aside, getting wxPython working seems like good progress from the POV
of mpl + pypy!

Tom

On Wed, Oct 19, 2016 at 3:05 PM Matti Picus <matti.picus at gmail.com> wrote:

> 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
> _______________________________________________
> 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: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161019/6b3e5a47/attachment.html>

From matti.picus at gmail.com  Wed Oct 19 16:35:03 2016
From: matti.picus at gmail.com (Matti Picus)
Date: Wed, 19 Oct 2016 23:35:03 +0300
Subject: [Matplotlib-devel] building from source with PyPy
In-Reply-To: <CAA48SF_g7ETsM35ZiRZPtbaWSWcX4U58Cm1bwCY+_NxP=DOuZg@mail.gmail.com>
References: <7772f64c-9f77-72e0-5012-6b16ae26c8ba@gmail.com>
 <CAA48SF_g7ETsM35ZiRZPtbaWSWcX4U58Cm1bwCY+_NxP=DOuZg@mail.gmail.com>
Message-ID: <f99fd344-3ca5-414a-da3b-d4d8f36ec7b2@gmail.com>

Sorry for the noise.

Matti


On 19/10/16 22:14, Thomas Caswell wrote:
> Matti,
>
> I think you sent this to the wrong mailing list?  This went to 
> matplotlib-devel, not the wxpython list ;)
>
> That aside, getting wxPython working seems like good progress from the 
> POV of mpl + pypy!
>
> Tom
>
> On Wed, Oct 19, 2016 at 3:05 PM Matti Picus <matti.picus at gmail.com 
> <mailto:matti.picus at gmail.com>> wrote:
>
>     Hi. I am a PyPy dev. Today I tried building wxPython Phoenix using
>     PyPy,
>     and would like to share my experience :).
>
>     ...
>     Matti
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>


From pmhobson at gmail.com  Sun Oct 30 17:21:27 2016
From: pmhobson at gmail.com (Paul Hobson)
Date: Sun, 30 Oct 2016 14:21:27 -0700
Subject: [Matplotlib-devel] [matplotlib-devel] The GitHub labels
In-Reply-To: <CAE-UAvQXf7rGHSML4rH9UG0XXFbYTFBzCBdML=VCC=_dwzCULA@mail.gmail.com>
References: <CAE-UAvQXf7rGHSML4rH9UG0XXFbYTFBzCBdML=VCC=_dwzCULA@mail.gmail.com>
Message-ID: <CADT3MEAgtN3KaEhybyX9-k+OXShE+9-fMK0qD9gr000emExPAg@mail.gmail.com>

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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161030/bbc6d93a/attachment.html>

From tcaswell at gmail.com  Mon Oct 31 09:55:45 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 31 Oct 2016 13:55:45 -0000
Subject: [Matplotlib-devel] [matplotlib-devel] The GitHub labels
In-Reply-To: <CAE-UAvQXf7rGHSML4rH9UG0XXFbYTFBzCBdML=VCC=_dwzCULA@mail.gmail.com>
References: <CAE-UAvQXf7rGHSML4rH9UG0XXFbYTFBzCBdML=VCC=_dwzCULA@mail.gmail.com>
Message-ID: <CAA48SF-dqXScvvoJG++BJepbKb_m7r5mToJJY+OCg=fqpc1-rA@mail.gmail.com>

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 at gmail.com>
Date: Sat, Oct 29, 2016 at 5:46 PM
Subject: [matplotlib-devel] The GitHub labels
To: matplotlib-devel at lists.sourceforge.net <
matplotlib-devel at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161031/6f514a8a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matplotlib_labels.png
Type: image/png
Size: 66301 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20161031/6f514a8a/attachment-0001.png>