read_csv/read_excel/read_hdf should create string labels, not "object" labels

[gdementen]

This is due to the underlying libraries (pandas and xlwings) but we get affected anyway.

>>> a = ndtest((2, 2, 2)).combine_axes(('a', 'b'))
>>> a
a_b\\c	c0	c1
a0_b0	0	1
a0_b1	2	3
a1_b0	4	5
a1_b1	6	7
>>> a.to_csv('test.csv')
>>> a.a_b.labels.dtype
dtype('<U5')
>>> b = read_csv('test.csv')
>>> b.a_b.labels.dtype
dtype('O')
>>> b.split_axes()
TypeError: string operation on non-string array
>>> c = b.set_labels('a_b', b.a_b.labels.astype(str))
>>> c.split_axes()
a	b\\c	c0	c1
a0	b0	0	1
a0	b1	2	3
a1	b0	4	5
a1	b1	6	7

There are several things we can do :

• implement Axis.astype() (would only make it a tiny bit less painful but would make sense anyway to implement)
• fix split_axes on object labels
• fix read_csv/read_hdf/read_excel to return str instead of object

[gdementen]

IMO fixing split_axes on object labels is the real high priority bug

[gdementen]

split_axes on object labels is fixed. The two other "issues" remain

[gdementen]

unsure it is worth it to fix quickly. The cost/benefit ratio is probably high.

[gdementen]

I do not think we should fix this anytime soon, at least unless it causes other problems down the line that we cannot fix in another way. Pandas has used object labels for years now and except for the non-optimal performance I don't know of any problem it has caused. As for what we are concerned, the non-optimal performance would be even worse and not better if we converted back to numpy str (simply because that is extra work). We might want to implement astype though but I guess that should be a separate issue.