Hiding labels in a legend?

Hello-
Prior to version 1.2 of MPL I was able to hide labels for certain
lines in the legend by setting the label=None when plotting a line,
however in 1.2 it is now showing the legend entry and visibly printing
"None". Is there a workaround to hide the label?

Thanks,
David

I think you want “nolegend” for those labels. The hiding of the labels for None was an undocumented feature, I think, and has been “fixed”.

http://matplotlib.org/api/axes_api.html#matplotlib.axes.Axes.legend

Cheers!
Ben Root

···

On Tue, Jan 22, 2013 at 1:57 PM, David Erickson <halcyon1981@…287…> wrote:

Hello-

Prior to version 1.2 of MPL I was able to hide labels for certain

lines in the legend by setting the label=None when plotting a line,

however in 1.2 it is now showing the legend entry and visibly printing

“None”. Is there a workaround to hide the label?

Thanks,

David

Perfect, thanks Ben!

-David

···

On Tue, Jan 22, 2013 at 1:20 PM, Benjamin Root <ben.root@...1304...> wrote:

On Tue, Jan 22, 2013 at 1:57 PM, David Erickson <halcyon1981@...287...> > wrote:

Hello-
Prior to version 1.2 of MPL I was able to hide labels for certain
lines in the legend by setting the label=None when plotting a line,
however in 1.2 it is now showing the legend entry and visibly printing
"None". Is there a workaround to hide the label?

Thanks,
David

I think you want "_nolegend_" for those labels. The hiding of the labels
for None was an undocumented feature, I think, and has been "fixed".

http://matplotlib.org/api/axes_api.html#matplotlib.axes.Axes.legend

I have to say I disagree with this "fix". None was a nice, very intuitive way to hide the label. Many Python systems use None in that kind of role and I really doubt anyone is going to use None when they meant "None" so converting it to a string seems like a bad idea.

Ted

···

________________________________________
From: David Erickson [halcyon1981@...287...]
Sent: Tuesday, January 22, 2013 4:47 PM
To: Benjamin Root
Cc: matplotlib-users@lists.sourceforge.net
Subject: Re: [Matplotlib-users] Hiding labels in a legend?

On Tue, Jan 22, 2013 at 1:20 PM, Benjamin Root <ben.root@...1304...> wrote:

On Tue, Jan 22, 2013 at 1:57 PM, David Erickson <halcyon1981@...287...> > wrote:

Hello-
Prior to version 1.2 of MPL I was able to hide labels for certain
lines in the legend by setting the label=None when plotting a line,
however in 1.2 it is now showing the legend entry and visibly printing
"None". Is there a workaround to hide the label?

Thanks,
David

I think you want "_nolegend_" for those labels. The hiding of the labels
for None was an undocumented feature, I think, and has been "fixed".

http://matplotlib.org/api/axes_api.html#matplotlib.axes.Axes.legend

Perfect, thanks Ben!

-David

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net

IIRC, the problem is that in matplotlib, the python None has a special meaning in most places (“do the default thing”). Legends, by default, will create default labels. For some time, we were capable of distinguishing when someone submitted label=None and didn’t state anything at all for labels. This often causes confusion down the draw stack, and we have been working towards getting rid of such distinctions.

Of course, this is all from memory, which is notoriously bad. If someone else can bisect the commit that changed this, maybe that can refresh my memory and maybe I could see a reason to re-instate this behavior. Also, if anyone can spot where it is stated in the documentation or examples that None acts the same as “nolegend”, then we can consider this a regression and get it fixed.

Cheers!
Ben Root

···

On Tue, Jan 22, 2013 at 9:10 PM, Drain, Theodore R (343P) <theodore.r.drain@…369…> wrote:

I have to say I disagree with this “fix”. None was a nice, very intuitive way to hide the label. Many Python systems use None in that kind of role and I really doubt anyone is going to use None when they meant “None” so converting it to a string seems like a bad idea.

Ted

If None means do the default thing, then great. I always interpreted the default for a plot command (line, patch, scatter, bar, etc.) to be no legend entry, unless explicitly given. While not the specification as you have given it (default is default labels), this is my working specification (I have not yet migrated to 1.2.0).

Cheers,
Sterling

PS Notwithstanding this possible point of difference of opinion, I think the matplotlib team is awesome, and puts out a great product. So I am willing to concede the point if no reversion is made.

···

On Jan 22, 2013, at 7:01PM, Benjamin Root wrote:

On Tue, Jan 22, 2013 at 9:10 PM, Drain, Theodore R (343P) <theodore.r.drain@...369...> wrote:
I have to say I disagree with this "fix". None was a nice, very intuitive way to hide the label. Many Python systems use None in that kind of role and I really doubt anyone is going to use None when they meant "None" so converting it to a string seems like a bad idea.

Ted

IIRC, the problem is that in matplotlib, the python None has a special meaning in most places ("do the default thing"). Legends, by default, will create default labels. For some time, we were capable of distinguishing when someone submitted label=None and didn't state anything at all for labels. This often causes confusion down the draw stack, and we have been working towards getting rid of such distinctions.

Of course, this is all from memory, which is notoriously bad. If someone else can bisect the commit that changed this, maybe that can refresh my memory and maybe I could see a reason to re-instate this behavior. Also, if anyone can spot where it is stated in the documentation or examples that None acts the same as "_nolegend_", then we can consider this a regression and get it fixed.

Cheers!
Ben Root