API: should the RangeIndex constructor accept start=range_index? (original) (raw)

xref #11892 (see changes and discussion)

RangeIndex, a new Int64Index subclass that will be used as the new default index (currently) has the following signature: RangeIndex(start=None, stop=None, step=None, name=None...)

For converting an xrange/range object into a RangeIndex, we have the constructor RangeIndex.from_range.

Although it isn't documented, the current constructor supports accepting a RangeIndex instances as the start argument, in which case a copy of the original index is produced, e.g., RangeIndex(RangeIndex(0, 10, 1)) -> RangeIndex(0, 10, 1).

I think this is a mistake: it is reusing the start parameter for a different type of argument, at odds with the documented behavior and predictable function signatures. If a user wants to create another RangeIndex from a RangeIndex, they can simply use the Index construtor, e.g., Index(RangeIndex(...)).

@jreback argues that not accepting a RangeIndex as the first argument to RangeIndex would be an API break, because it would create an Index constructor that is not idempotent. It would be "a major break with the current Index design".

Thoughts from anyone else?