Repository navigation
Bug in AxesStack.add #7194
Description
I think I've found a bug where the format of data actually stored in Stack is different from that expected in Stack.remove. It seems that the line below needs to be:
Stack.remove(self, self._entry_from_axes(a_existing))
I don't have a minimal repro case (probably something to do with multi-threading in a tensorflow py_func), but I've been seeing exceptions in the .remove method. Adding some more useful exception messaging shows me a missing self._ind 0th tuple element.
AxesStack.add(((1, 1, 1), ()),..): Axes(0.125,0.1;0.775x0.8) vs Axes(0.125,0.1;0.775x0.8)
^key ^ a ^a_existing
matplotlib/cbook.py", line 1410, in remove
raise ValueError('Unknown element o: %s vs %s' % (o, self._elements))
Unknown element o: (((1, 1, 1), ()), <matplotlib.axes._subplots.AxesSubplot object at 0
x7fd416508550>) vs [(((1, 1, 1), ()), (1, <matplotlib.axes._subplots.AxesSubplot object at 0x7fd416
508550>))]
def add(self, key, a):
"""
Add Axes *a*, with key *key*, to the stack, and return the stack.
If *a* is already on the stack, don't add it again, but
return *None*.
"""
# All the error checking may be unnecessary; but this method
# is called so seldom that the overhead is negligible.
if not isinstance(a, Axes):
raise ValueError("second argument, %s, is not an Axes" % a)
try:
hash(key)
except TypeError:
raise ValueError("first argument, %s, is not a valid key" % key)
a_existing = self.get(key)
if a_existing is not None:
HERE--> Stack.remove(self, (key, a_existing))
warnings.warn(
"key %s already existed; Axes is being replaced" % key)
# I don't think the above should ever happen.
if a in self:
return None
self._ind += 1
return Stack.push(self, (key, (self._ind, a)))
To help us understand and resolve your issue please check that you have provided
the information below.
- Matplotlib version, Python version and Platform (Windows, OSX, Linux ...)
- How did you install Matplotlib and Python (pip, anaconda, from source ...)
- If possible please supply a Short, Self Contained, Correct, Example
that demonstrates the issue i.e a small piece of code which reproduces the issue
and can be run with out any other (or as few as possible) external dependencies. - If this is an image generation bug attach a screenshot demonstrating the issue.
- If this is a regression (Used to work in an earlier version of Matplotlib), please
note where it used to work.
Activity
brianwa84 commentedon Sep 28, 2016
Also: you'll want to change the warnings.warn line to use str(key). Otherwise once you fix the line in question, you get an exception
TypeError: not all arguments converted during string formatting
tacaswell commentedon Sep 28, 2016
I am having a hard time understanding what is going on here (and which parts of the above are existing code, which parts are output, and which parts are your markup on either of the above).
brianwa84 commentedon Sep 28, 2016
Sorry, I'll try to be a bit clearer:
The bug is here:
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/figure.py#L130
The issue is that a_existing is an Axes object, whereas the items in self._elements are tuples of (key, (index, Axes)) (see the Stack.push call on L138). So when you try to remove a tuple of (key, Axes), Stack fails with the cryptic exception "Unknown element o". If you muck with the code in Stack.remove to throw ValueError("Unknown element o: %s vs %s" % (o, self._elements)), you get what I pasted in there. That's the indication that the (index,Axes) tuple has been swapped for Axes.
brianwa84 commentedon Sep 28, 2016
brianwa84 commentedon Sep 29, 2016
My local patch is as follows:
JunTan commentedon Oct 18, 2016
Did you define plt somewhere else? I got this error when I the above code.
brianwa84 commentedon Oct 19, 2016
Yes somewhere I probably import matplotlib.pyplot as plt
On Oct 18, 2016 6:07 PM, "JunTan" [email protected] wrote:
anntzer commentedon Sep 16, 2017
Closing as we're just going (in the long run) to deprecate AxesStack (or rather, make it private). See #9037 and linked issues.