I think we are happy to help, but we make no guarantee to support all numpy-like objects that exist in the python universe. If you want help with this I suggest figuring out how to reproduce w/o tensorflow so we can advise.

This looks like a failure of the up-cast to 2D logic (and instead of 1 histogram of N elements we are seeing N histograms of 1 element).

Specifically this code:

which recently got re-worked due to changes in how numpy auto-up-casts object / ragged arrays.

I suggest figuring out how to reproduce w/o tensorflow so we can advise

The Tensorflow failure is the only case I know, and it's how I ended up reporting this bug. I was just trying to learn the Numpy emulation in Tensorflow.

I think the two problems are:

1. Matplotlib preprocesses instances of np.ndarray so they are always 2D, with vectors gaining an outer dimension. The tensorflow object doesn't get this preprocessing. (Matplotlib should probably be using __array__ here?)

2. The introspection of the elements in X to test for iterableness (which lets a normal sequence of numbers work as expected) fails because the elements of the tensorflow object are 0D but an instance of Iterable:

from collections.abc import Iterable
print(isinstance(labels1[0], Iterable))
print(isinstance(labels2[0], Iterable))

It is reasonable to expect that we will ducktype TF arrays correctly here. For now I think there is a user-space work around to cant to numpy before passing to us. That said, none of the core developers are regular TF users so any help with duck-typing them correctly would be greatly appreciated.

Internally we can not directly use np.asarray before handling units because that will break things like pint, but checking for __array__ may work better?

Labeled this as good first issue because I think all of the work that needs to be done is in _reshape_2D and requires little understanding of the rest of Matplotlib internals.

I think it is desirable to ducktype what we can, but we need some rules for what that means. Random object x used to work, but now it doesn't is not a good argument that random x should ever have worked. It would be preferable to try and stipulate what properties x needs to have for successful duck typing.

Isn't that what obj.__array__ is for?

Long term we can rely on the behavior defined by https://data-apis.org/blog/array_api_standard_release/ but for now I suspect we are going to have to keep playing whack-a-mole with these.

As discussed on the dev call: We are happy to take a patch that improves the duck typing here, and provides a mock class that behaves like the object so that we can run tests. We cannot take downstream libraries as a test dependency (except for pandas) so someone will have to go through the effort of making a mock.

In user space, please convert to a numpy array or list of lists or list of numpy arrays. Nothing else is documented or guaranteed to work. While we don't try to break things, passing other objects are not guaranteed to be stable.

Downstream libraries should be able to avoid these problems by providing a to_numpy method. Its possible we could check for __array__ as well, but it would be nice to have a test object to work with so we can test that. (In this case its not clear that will work if array elements are all going to be Iterable.)

I'll close because we don't have an immediate action, but again we very much welcome feedback either as a new self-contained issue or PR. Re-opening at @tacaswell request - we will definitely still take a PR for this.

(In this case its not clear that will work if array elements are all going to be Iterable.)

If _reshape_2D duck-typed ndarrays, this wouldn't be an issue because the tensorflow object would be 2D when you get to that check. But it's an added wrinkle that explains why it doesn't work as you might expect from the fact that the tensorflow array looks like a vector.

Pushed to 3.5. I think the action items here are

1. we need to document what we expect to work or not so that in the future we can have a clear line of what we
2. we would likely take a patch to cbook that handles the reality of what TensorFlow is doing because we do not have 1 yet.

Is this really a good first issue?

Probably 2. can be done as a first issue.

For 1. I don't think we even know what we expect.

I think part 2 is a good first issue to Matplotlib for someone who is fluent in tensorflow and array conventions.

Hello, I need clarity on this issue more correctly I couldn't get it . The problem is only with the matplotlib 3.3.4 version, as with the latest version 3.4.3 version it shows correct output on google colab. I am new here and I attempting to first time. Please help me understand.

Are you using the same version of tensorflow with both mpl3.4.3 and mpl3.3.4?

If not, it could be that something changed on the TF side to match our expectation of what an "array" is better.

If so, then maybe we accidentally fixed this and it can be closed!

I have used mpl 3.4.3 with tensorflow 2. I haven't worked with mpl 3.3.4. It works fine with mpl 3.4.3 with tensorflow 2.

Do you get the same results as in this comment?

from collections.abc import Iterable
print(isinstance(labels1[0], Iterable))
print(isinstance(labels2[0], Iterable))

@mwaskom I am not sure about the idea mentioned in that comment. I just tried getting the plot with the given code and it worked fine.

Can you try running that code in the environment where the plot works?

I have tried running it. It works fine with mpl 3.4.3 and tensorflow 2

Yes but what does it print?

See above comment https://github.com/matplotlib/matplotlib/issues/19574#issuecomment-902075023. I have attached the output I got.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

I don't know whether this is still an issue (I think so) but something is a little whacky about this bot: it has been a lot more than 365 days since the last comment here.

I guess if we wanted to be strict, the bot message could say "it has been over 365 days since the last update". It's basically just working through the issue backlog and checking update timestamps.

To clarify further, we set a limit of how many issues get checked and how often so that they don't all get closed at once with no chance for comment.