2.1 figure.legend broken

Bug report

figure.legend no longer accepts "handles" and and "labels" as keywords

Code for reproduction

# Paste your code here
#
#
fig.legend(
    handles = patches,
     labels = labels,
    ...)

**Actual outcome**

<!--The output produced by the above code, which may be a screenshot, console output, etc.-->

If applicable, paste the console output here

~/Python/lib/python3.6/site-packages/matplotlib/figure.py in legend(self, *args, **kwargs)
1523 '(artist handles, figure labels, legend location)')
1524
-> 1525 l = Legend(self, handles, labels, **kwargs)
1526 self.legends.append(l)
1527 l._remove_method = lambda h: self.legends.remove(h)
TypeError: init() got multiple values for argument 'handles'


**Expected outcome**

<!--A description of the expected outcome from the code snippet-->
<!--If this used to work in an earlier version of Matplotlib, please note the version it used to work on-->

**Matplotlib version**
<!--Please specify your platform and versions of the relevant libraries you are using:-->
  * Operating system: Fedora 26
  * Matplotlib version: 2.1
  * Matplotlib backend (`print(matplotlib.get_backend())`): TkAgg
  * Python version: 3.6.3
  * Jupyter version (if applicable):
  * Other libraries: 

<!--Please tell us how you installed matplotlib and python e.g., from source, pip, conda-->
<!--If you installed from conda, please specify which channel you used if not the default-->

**Fix**

if handles and labels are provided as kwargs, use these and pop from kwargs.

There is many more issues. mpl 2.1.0 is not a production version.

Can you please provide a runnable example?

import numpy as np
import matplotlib.pyplot as plt

fig, ax = plt.subplots(1, 2)
hs = []
for axx in ax:
    h = axx.plot(np.arange(10))
    hs += [h]
fig.legend(handles=hs, labels=['Boo', 'Hoo'])
plt.show()

Doesn't make a legend and returns:

/Users/jklymak/anaconda3/envs/matplotlibdev/lib/python3.6/site-packages/matplotlib/figure.py:1505: UserWarning: No labeled objects found. Use label='...' kwarg on individual plots.
  warnings.warn("No labeled objects found. "

This is using master.

@dstansby

@dstansby It looks like you maybe made this change? Are we dropping support for handles and labels keywords?

@2sn : positional arguments work, and indeed the documented version of figure.legend don't make mention of supporting handles=:

fig, ax = plt.subplots(1, 2)
hs = []
lab = ['Boo', 'Hoo']
for nn, axx in enumerate(ax):
    h, = axx.plot(np.arange(10))
    hs += [h]
fig.legend(hs, lab)
plt.show()

Do you have a PR/commit reference for where I made the change? Can't remember anything like this off the top of my head.

@dstansby

@dstansby #7811, I think. However, I have no idea if handles= and labels= were ever supported. Also please note I edited the comment above as I'd done something silly ;-)

According to the 2.0 docstring, legend() never accepted handles and labels as kwargs, but instead as normal arguments. If it worked before I guess it was a co-incidence. The 2.1 docstring also doesn't mention them as kwargs, so I don't think anything is technically wrong, but it seems sensible to support them as kwargs so will leave this open.

In the mean time, just dropping handles= and labels= should fix the problem.

Because they were named args before, the expectation is that they will work as kwargs as well. This is a regression that should be fixed (and it is a easy fix, just check if they are in kwargs before falling back to searching).

axes.legend allows them to be kwargs as well. axes.legend also allows just passing one argument, a list of the labels. I'm not sure if we want to do that...

I'd fix this, but I don't understand why handles, labels, and loc aren't still named positional args that default to None. Do we not like positional arguments?

Also makes scikit-learn doc builds fail at https://github.com/scikit-learn/scikit-learn/blob/master/examples/neural_networks/plot_mlp_training_curves.py#L88

See or #9324 for possible fix. However I wouldn’t expect every invocation combination to be respected.

Yes, I had looked at the source file rather than the doc and used the names positional arguments from there. I think it is better being able to give them as named arguments that can be passed as keywords so you don't have to remember the order. Explicit is better. Thanks for fixing!

PS - I have edited my code to now use positional arguments, but the old behaviour was nicer.

Navigation Menu

Repository navigation

2.1 figure.legend broken #9320

Bug report

If applicable, paste the console output here

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

2.1 figure.legend broken #9320

Description

Bug report

If applicable, paste the console output here

Activity

2sn commented on Oct 8, 2017

tacaswell commented on Oct 8, 2017

jklymak commented on Oct 8, 2017

jklymak commented on Oct 8, 2017

dstansby commented on Oct 8, 2017

jklymak commented on Oct 8, 2017

dstansby commented on Oct 8, 2017

tacaswell commented on Oct 8, 2017

jklymak commented on Oct 8, 2017

jnothman commented on Oct 9, 2017

jklymak commented on Oct 10, 2017

2sn commented on Oct 11, 2017

2sn commented on Oct 11, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions