GeezerVison

I don't think the figure name should appear in the canvas. Naming a figure is not the same thing as giving a figure or axes a title.

This is done only in the image comparison test.
The aim of that test is to check that plotting works ok with named figures.
To ensure plotting is done on the correct figure, it is useful to draw the
figure name on the output.

Le , ddale
[email protected]
a crit :

I don't think the figure name should appear in the canvas. Naming a
figure is not the same thing as giving a figure or axes a title.

Reply to this email directly or view it on GitHub:

#147 (comment)

To elaborate my comment on the source code, here is an example

import matplotlib.pyplot as plt
f1 = plt.figure("1")
f2 = plt.figure("2")
f3 = plt.figure("3")
   
plt.close("1")
from matplotlib.pyplot import _pylab_helpers
figManagers = _pylab_helpers.Gcf.get_all_fig_managers()
print [m.num for m in figManagers]

And it prints out

[2, 3]

We may use a dictionary that maps labels to figure numbers.

There was a mistake in the code (corrected below).

I don't think Dictionnary access is possible because labels are not guaranteed to be unique.

correct version:
if figLabel not in allLabels:
if len(allLabels):
num = max(allnums) + 1
else:
num = 1
else:
num = allLabels.index(figLabel)
num = allnums[num]

Please push your changes into your repo.

Eric commented on the issue of using "all" as a figure name (#99 (comment)). And I think it is better to explicitly prevent it from being used.

What is the desired behavior when a new figure('all') is created ?

1. create figure
2. create figure + warn
3. do not create figure + warn

I think 'all' is a reasonable value for creating/selecting a named figure. It's only if close('all') is called that there is a possible issue. Therefore, I would go with solution 2).

the warning message could be the following:
warning: using figure name 'all' is not recommended because calling close('all') will close all existing figures instead of just figure 'all'. figure('all') was created.

Okay. With a reasonable warning message, option 2 should be good.

The feature is fully implemented and ready for pull.

This seems to me like a useful and logical feature, and a bit of testing turned up no surprises, so I saw no reason not to merge it.