At the moment you have to use MI.from_arrays or MI.from_tuples
I think it would be nicer to be able to call MultiIndex directly (and have an orient argument, similar to some other functions). Perhaps even with a little guess work to decide what the user wants similar to other contructors.
Comment From: jtratner
this also has the advantage of making the self._constructor more usable for MultiIndex.
Comment From: jreback
pushing to 0.14. Is this covered by another issue? @jtratner
Comment From: jtratner
So far, all we are planning is to move those methods to Index and allow you to pass levels and labels to Index to construct a MultiIndex.
So not superseded by anything else. We could move from_arrays into the
Index constructor because it's simple to check. (can only have hashable
objects in an index anyways). moving from tuples could be harder to do in a
backwards compatible way.
Comment From: jreback
closed by #6055
Comment From: hayd
@jreback Is this really fixed? Intention was that this would create an mi:
pd.MultiIndex([(1, 2)]) # possible orient kwarg
atm you have to pass labels and levels...
Comment From: jreback
I think MultiIndex.from_product 'fixes' this, don't you
Comment From: hayd
Issue's intention was something like this:
In [11]: pd.MultiIndex([(1, 2)]) # would do pd.MultiIndex.from_tuples([(1, 2)])
Out[11]:
MultiIndex(levels=[[1], [2]],
labels=[[0], [0]])
In [12]: pd.MultiIndex([(1, 2)], orient=?) # would do pd.MultiIndex.from_arrays([(1, 2)])
Out[12]: Int64Index([1, 2], dtype='int64')
Perhaps this is not feasible with current constructor args... ?
Comment From: jreback
I am not sure what this buys you; their are 3 ways to create MI right now (with from_product being the most useful). Do we really need a 4th way? (and I don't think it possible to 'guess'); you are suggesting a keyword arg to MultiIndex basically select tuples/array/product?
Comment From: TomAugspurger
Agreed, we don't need to overload init