Thanks! The problem is that pandas dataframes store all string arrays as opaque "objects" and under normal usage this is true, but apparently sometimes pandas can decide to call an integer column "objects" (which I'm sure does wonders for performance), and this was tripping up my code. I couldn't write a specific test for this since I couldn't figure out how to get a pandas dataframe into that state in over an hour of banging my head against it. Inspecting the arrow table for which columns are string columns works because arrow itself checks all the values in a pandas dataframe to figure out the datatype anyway (I assume because pyarrow knows that pandas can't be trusted when it says what type a column is). (FYI, this is all buried in the pyarrow cython code, and not obviously documented anywhere.)

Ok, I approved the PR, and it's fine to not add tests. However, if pandas_to_arrow is well covered shouldn't the tests have been failing? Surely the arrays used aren't all things with a len()? I'm sure I'm missing some subtelty.

This is a very subtle thing, but this code is exercised via configuration in the formatter such that a write of a dataframe always uses pandas_to_arrow and a read of an arrow table to a dataframe always uses arrow_to_pandas. If it weren't run at all, the coverage tool would pop up boxes on the files in the PR. (And trust me, when I first did there were a lot of boxes.)

I saw that nothing in the unit tests uses pandas_to_arrow except a test with an empty array. Would it be worthwhile to add some tests that do a round trip pandas_to_arrow and arrow_to_pandas, or something similar?