@tacaswell, thanks for your review, but dismissing as this approach is completely different, and attempts to remove the pandas-ness of the data right at the beginning.

This gets used in_plot_args, usually viaindex_of (which adds a y if it is missing).

and it gets calledbefore we check units. So I guess what I am proposing here would strip an object that has ato_numpy method but somehow was being used by somebody for units.

This does give me pause that we have maybe done the wrong thing here, and are using_check_1d to both coerce a singleton to an arrayand to convert pandas series and dataframes to arrays. Maybe theright thing to do is just return the DataFrame, run through the converter, andthen coerce to numpy if it is not already.

Meh, it has done this conversion for a long time.

@tacaswell, this simplified a bit more since your approval - if you wanted to double check, that would be appreciated.

In#22560 I addedcbook._unpack_pandas (so_unpack_pandas for this purpose) which basically doesto_numpy(), but also with a fallback tovalues. I did not touch the lines you changed here though.

I guess it can make sense to have a coordinates merge of this and that PR. If this is merged first, I'll update my PR. If my PR is merged first, it can make sense to use that function here.

Well first it's not only pandas that has to_numpy so that is a bit of a misnomer. But also, why have a separate method at all?

It was suggested to use a separate function. Right now, slightly different approaches are used at different locations in the code. Sometimes a fallback tovalues, sometimes not. A benefit is possibly that it is enough to modify it in a single location (and that old Pandas versions are still supported with this fallback). Also, if we want to support new libraries that with some other name, it will be easy to do that. Well, all the standard reasons to factor out a piece of common code...

Regarding naming, I considered that, but I do not know which other libraries support that function. However, I do not really see the name neither written in stone nor something that should prohibit using a single function, there will be a name that is correct enough. (And as you can see, there are explicit comments mentioning pandas at all the other locations where it was used.)

I then assume that we merge this first, find a good name for the function and, if you want to strongly object using the function here, you can do that in#22560.

I meant why have a separate method than check_1d? Our problem is inconsistent duckttping so if we can have it all in one spot that would be very helpful. If check1d does more than duck type pandas then sure it could call the ducktype converter.

I do actually wonder if all of this should just be part of the unit conversion machinery rather than cbook calls

I meant why have a separate method than check_1d?

I do not have an enough overview of the code base to see if one should/could have used check_1d (or check_2d?) instead. But if possible, that is of course even better.