Hi,
According to the legend doc,
If label is set to '_nolegend_', the item will not be shown in
legend.
But I think the documented behavior a bit ambiguous. For example,
consider the example below.
l1, = plot([1,2,3], label="_nolegend_")
l2, = plot([2,3,1])
legend(["my line"])
I suppose the legend should show *l2* with "my line" label. But the
current master branch shows "l1" with "my line" label.
In other words, in the current implementation, when the legend command
is called with a single nonkeyword argument (which is interpreted as a
list of labels), the given labels are applied to all the artists
regardless whether the artist has a label of "_nolegend_" or not.
While there could be some cases that have relied on this behavior, I'm
inclined to fix this so that artists w/ "_nolegend_" are ignored.
However, fixing this requires "hist" command to be modified (there
could be more commands that need modification).
Unless there is no objection from other developers, I'll go ahead and
commit the patch to fix this.
Regards,
-JJ
I agree, the current behavior is buggy.
Ben Root
···
On Sun, Mar 6, 2011 at 7:18 AM, Jae-Joon Lee <lee.j.joon@…149…> wrote:
Hi,
According to the legend doc,
If label is set to '_nolegend_', the item will not be shown in
legend.
But I think the documented behavior a bit ambiguous. For example,
consider the example below.
l1, = plot([1,2,3], label="_nolegend_")
l2, = plot([2,3,1])
legend(["my line"])
I suppose the legend should show l2 with “my line” label. But the
current master branch shows “l1” with “my line” label.
In other words, in the current implementation, when the legend command
is called with a single nonkeyword argument (which is interpreted as a
list of labels), the given labels are applied to all the artists
regardless whether the artist has a label of “nolegend” or not.
While there could be some cases that have relied on this behavior, I’m
inclined to fix this so that artists w/ “nolegend” are ignored.
However, fixing this requires “hist” command to be modified (there
could be more commands that need modification).
Unless there is no objection from other developers, I’ll go ahead and
commit the patch to fix this.
Regards,
-JJ