Let MultiIndex accept a list-like as input

[topper-123]

In #22511 and #23752 I work on some changes to MultiIndex. It came up in discussion that the consteuction of MultiIndex shold be changed, so that initialising with a list of tuples should be accepted:

>>>pd.MultiIndex([('a', 1)
...               ('b', 2)])
MultiIndex([('a', 1)
            ('b', 2)])

I'm also thinking that MultiIndex could accept dicts when initialising, and it would work similarly, except the dict keys would become the values for MultiIndex.names, and the dict values would be level values for the MultiIndex.

[ms7463]

The arrays/dictionary initialization would be covered in the from_data proposal from this PR: #23141. Although pd.MultiIndex.from_arrays/from_tuples would already cover list-like input.

@jreback / @toobaz / @TomAugspurger - does this add any merit to from_data over the dedicated from_frame?

[gfyoung]

I'm confused here...don't we already have MultiIndex.from_tuples ? Are we just integrating that behavior directly into the constructor?

[jreback]

the proposal to make the default constructor to this

[topper-123]

@gfyoung , Yes, basically the proposal is to default constructor accept the arguments from from_tuples + plus others, so this should be fully backwards compatible.

[gfyoung]

@topper-123 : Yep, that makes sense. +1 from me.

[shoyer]

I don't think this makes sense. The default pd.MultiIndex constructor intentionally mirrors the under-lying data-structure (in terms of levels and codes). It's OK if users don't use the constructor directly -- we can aways make convenience functions for that (which indeed already exist). We could even make a new "try everything" converter function pd.to_multiindex(), though I'm not sure how you could reliably distinguish from_tuples from from_arrays.

There is no iron-clad rule that a class's repr needs to use its constructor directly -- we could make the repr show MultiIndex.from_tuples(...) if desired. The situation is pretty similar to that for np.ndarray (with its low-level constructor) and np.array (which is used in the repr).

If you did go ahead with this, what would you do with the existing constructor? Would you delegate the existing constructor to another method, or would you simply overload the first argument levels to check for a list of tuples? This sort of heavy overloading makes code harder to understand and error check (either manually or with static checks like mypy/pylint).