MultiIndex.from_tuples returns an Index when all tuples are length 1

[TomAugspurger]

In [1]: import pandas as pd
In [2]: pd.MultiIndex.from_tuples([('a',), ('b',)])
Out[2]: Index(['a', 'b'], dtype='object')

This should return a MultiIndex I think, like

Out[5]:
MultiIndex(levels=[['a', 'b']],
           labels=[[0, 1]])

Well, pd.MultiIndex([['a', 'b']], [[0, 1]]) returns the same thing as from_tuples (an index) so maybe this is intentional.

Trying to figure out if this is intentional or not (this came up in my categorical dtype refactor).

[jreback]

i think there is another identical issue to this

[TomAugspurger]

Ahh dang, it does seem to be intentional:

pandas/pandas/tests/indexes/test_multi.py

Line 539 in 929c66f

def test_constructor_single_level(self):

also I messed up my expected, editing now.

[TomAugspurger]

i think there is another identical issue to this

I thought so too, but I couldn't find it. Perhaps it was the other way around (Index constructor returning a MultiIndex if passed tuples)?

[TomAugspurger]

What do you think API-wise @jreback? Add a keyword to control the automatic squeeze to the Index, similar to how pd.Index(...) has tupleize_cols?

[jreback]

no kwargs this is correct

a non nested tuple is a list-like

[TomAugspurger]

Ok, this will require some extra workarounds for the categorical dtype refactor then. It'd be nice if MultiIndex.from_tuples always returned an actual MultiIndex, not dependent on the values passed.

[TomAugspurger]

a non nested tuple is a list-like

As an example where this breaks down, we don't apply this rule everywhere:

In [1]: import pandas as pd
In [2]: pd.Categorical([('a',), ('b',)])
Out[2]:
[(a,), (b,)]
Categories (2, object): [(a,), (b,)]

That's on master. On my branch I get an exception since I try to call hash_tuples, but that assumes that MultiIndex.from_product always returns a MultiIndex, since it checks levels immediately after, without checking to see that a MultiIndex was returned.

[jreback]

As an example where this breaks down, we don't apply this rule everywhere:

this is not the same.

[TomAugspurger]

I just really don't see a reason for this

In [2]: from pandas.core.util.hashing import hash_tuples

In [3]: hash_tuples([('a',), ('b',)])
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-3-3114ee1a48d2> in <module>()
----> 1 hash_tuples([('a',), ('b',)])

~/Envs/pandas-dev/lib/python3.6/site-packages/pandas/pandas/core/util/hashing.py in hash_tuples(vals, encoding, hash_key)
    154                         ordered=False,
    155                         fastpath=True)
--> 156             for level in range(vals.nlevels)]
    157
    158     # hash the list-of-ndarrays

~/Envs/pandas-dev/lib/python3.6/site-packages/pandas/pandas/core/util/hashing.py in <listcomp>(.0)
    154                         ordered=False,
    155                         fastpath=True)
--> 156             for level in range(vals.nlevels)]
    157
    158     # hash the list-of-ndarrays

AttributeError: 'Index' object has no attribute 'labels'

To be special cased by the caller every time someone wants to call hash_tuples. The cleanest fix is in the MultiIndex constructor.

[jreback]

see #14823

[TomAugspurger]

#14823 seems unrelated, unless I'm missing something These are all the same length (1).

The fix is essentially a one-liner: https://github.com/pandas-dev/pandas/compare/master...TomAugspurger:multiindex-squeeze?expand=1#diff-4ffd1c69d47e0ac9f2de4f9e3e4a118cR102

[jbrockmendel]

+1 for having MultiIndex.from_whatever consistently return a MultiIndex.