Add support to names keyword in Index

[pedrocunial]

• closes BUG: Creating Index name using names names argument, doesn't set index name #19082
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[WillAyd]

Can you move this to the end (before kwargs)

[pedrocunial]

Fixed this!

[WillAyd]

Not super familiar with this part of the code but is it possible to share the length of checking of names across the index types? This already fails for a MultiIndex:

>>> pd.MultiIndex.from_tuples((('a', 'b'), ('c', 'd')), names=('a', 'b', 'c'))

ValueError: Length of names must match number of levels in MultiIndex.

So ideally could share that machinery here

[pedrocunial]

I'm not a 100% sure I understood what you're saying here, but I removed the check for weather the data is a list-like.

Is that it?

[pedrocunial]

Hey @WillAyd I did some changes related to what you've commented, that being said, I'm not a 100% sure that I've understood your second comment.

[WillAyd]

To clarify my comment it looks like code has been added here to validate the names argument when called as part of the Index constructor. However, there also appears to be validation as part of the MultiIndex constructor (at least from an end user perspective - haven't dug deep in code).

Would there be a way to align those?

With that said I'm a little hesitant on this change. I understand the goal but it feels weird to have both a name and names argument as part of the constructor. Have to think through in more detail

[TomAugspurger]

With that said I'm a little hesitant on this change. I understand the goal but it feels weird to have both a name and names argument as part of the constructor.

I'd say that's an issue with the Index constructor's API. They're both valid arguments, this just updating the signature / docs to reflect that :)

[WillAyd]

They're both valid arguments, this just updating the signature / docs to reflect that :)

I assume that's just because the Index constructor appears to accept anything though, right? Not necessarily that it's valid.

>>> pd.Index([], name="foo")
Index([], dtype='object', name=['foo'])
>>> pd.Index([], names=["foo"])
Index([], dtype='object')
>>> pd.Index([], something="foo")
Index([], dtype='object')

[TomAugspurger]

It's used if you take the MultiIndex route

In [5]: pd.Index([(1, 2), (3, 4)], names=['a', 'b'], tupleize_cols=True)
Out[5]:
MultiIndex([(1, 2),
            (3, 4)],
           names=['a', 'b'])

[WillAyd]

Sorry I think I went in a circle but coming back to it...I don't see how having both name and names makes sense from an API perspective. I get we want to do that to achieve symmetry in our inheritance but from an end user perspective this feels like a step in the wrong direction

[jreback]

closing; we want to deprecate names I think, this is going backwards.