8000 Deprecate the Axes-reuse-if-same-args behavior. · matplotlib/matplotlib@d84c9ba · GitHub
[go: up one dir, main page]

Skip to content

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit d84c9ba

Browse files
committed
Deprecate the Axes-reuse-if-same-args behavior.
1 parent dd54033 commit d84c9ba

File tree

1 file changed

+23
-17
lines changed

1 file changed

+23
-17
lines changed

lib/matplotlib/figure.py

Lines changed: 23 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -91,6 +91,13 @@ def get(self, key):
9191
item = dict(self._elements).get(key)
9292
if item is None:
9393
return None
94+
cbook.warn_deprecated(
95+
"2.1",
96+
"Adding an axes using the same arguments as a previous axes "
97+
"currently reuses the earlier instance. In a future version, "
98+
"a new instance will always be created and returned. Meanwhile, "
99+
"this warning can be suppressed, and the future behavior ensured, "
100+
"by passing a unique label to each axes instance.")
94101
return item[1]
95102

96103
def _entry_from_axes(self, e):
@@ -901,14 +908,14 @@ def add_axes(self, *args, **kwargs):
901908
fig.add_axes(rect, projection='polar')
902909
fig.add_axes(ax)
903910
904-
If the figure already has an axes with the same parameters,
905-
then it will simply make that axes current and return it. If
906-
you do not want this behavior, e.g., you want to force the
907-
creation of a new Axes, you must use a unique set of args and
908-
kwargs. The axes :attr:`~matplotlib.axes.Axes.label`
909-
attribute has been exposed for this purpose. e.g., if you want
910-
two axes that are otherwise identical to be added to the
911-
figure, make sure you give them unique labels::
911+
If the figure already has an axes with the same parameters, then it
912+
will simply make that axes current and return it. This behavior
913+
has been deprecated as of Matplotlib 2.1. Meanwhile, if you do
914+
not want this behavior (i.e., you want to force the creation of a
915+
new Axes), you must use a unique set of args and kwargs. The axes
916+
:attr:`~matplotlib.axes.Axes.label` attribute has been exposed for this
917+
purpose: if you want two axes that are otherwise identical to be added
918+
to the figure, make sure you give them unique labels::
912919
913920
fig.add_axes(rect, label='axes1')
914921
fig.add_axes(rect, label='axes2')
@@ -996,14 +1003,14 @@ def add_subplot(self, *args, **kwargs):
9961003
-----
9971004
If the figure already has a subplot with key (*args*,
9981005
*kwargs*) then it will simply make that subplot current and
999-
return it.
1006+
return it. This behavior is deprecated.
10001007
10011008
Examples
10021009
--------
10031010
fig.add_subplot(111)
10041011
10051012
# equivalent but more general
1006-
fig.add_subplot(1,1,1)
1013+
fig.add_subplot(1, 1, 1)
10071014
10081015
# add subplot with red background
10091016
fig.add_subplot(212, facecolor='r')
@@ -1022,18 +1029,17 @@ def add_subplot(self, *args, **kwargs):
10221029
return
10231030

10241031
if len(args) == 1 and isinstance(args[0], int):
1025-
args = tuple([int(c) for c in str(args[0])])
1026-
if len(args) != 3:
1027-
raise ValueError("Integer subplot specification must " +
1028-
"be a three digit number. " +
1029-
"Not {n:d}".format(n=len(args)))
1032+
if not 100 <= args[0] <= 999:
1033+
raise ValueError("Integer subplot specification must be a "
1034+
"three-digit number, not {}".format(args[0]))
1035+
args = tuple(map(int, str(args[0])))
10301036

10311037
if isinstance(args[0], SubplotBase):
10321038

10331039
a = args[0]
10341040
if a.get_figure() is not self:
1035-
msg = ("The Subplot must have been created in the present"
1036-
" figure")
1041+
msg = ("The Subplot must have been created in the present "
1042+
"figure")
10371043
raise ValueError(msg)
10381044
# make a key for the subplot (which includes the axes object id
10391045
# in the hash)

0 commit comments

Comments
 (0)
0