Infer names in MultiIndex.from_product

[christopherzimmerman]

• closes Infer names in MultiIndex.from_product if inputs have a name attribute #27292
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[jschendel]

Thanks! A few comments but looks good overall.

[TomAugspurger]

To disable this, I now have to do

from_product(iterables, names=[None] * len(iterables)

Are we OK with that? Or do we want to allow names=None to continue to mean no names? If so, we'll need a different sentinel value that None (no_default = object())

[TomAugspurger]

But this above the .. _whatsnew_1000.api_breaking: line.

And maybe say "when not explicitly provided" rather than "if possible".

[jschendel]

Put this above the .. _whatsnew_1000.api_breaking: line.

It looks like a few of the section reference names are slightly misaligned with ticks throughout the whatsnew:

Enhancements
~~~~~~~~~~~~

.. _whatsnew_1000.enhancements.other:

-
-

Other enhancements
^^^^^^^^^^^^^^^^^^

.. _whatsnew_1000.api_breaking:

-
-

Backwards incompatible API changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. _whatsnew_1000.api.other:

- :class:`pandas.core.groupby.GroupBy.transform` now raises on invalid operation names (:issue:`27489`).

I'll open up a quick PR to fix it across the board. Might result in a merge conflict here but should be straightforward to resolve.

[christopherzimmerman]

I made the change to the text in whatsnew, holding off on changing anything else if jschendel is going to be changing other parts of the file.

[jschendel]

I just merged my changes to the whatsnew, so you should be good to make the additional changes now. Should just need to address the merge conflict by making sure your entry is above the .. _whatsnew_1000.api_breaking: line.

[christopherzimmerman]

@TomAugspurger in regards to your first comment, the reason I opened an issue about this in the first place was due to the addition of from_frame, which does infer names from the Series inputs, so it seemed like an inconsistency. If that behavior usually isn't wanted/needed in from_product, then maybe this PR isn't necessary.

[jreback]

you would also have to change from_arrays for the same reason. I think if you did that would be ok with this (ex using @TomAugspurger suggestion, that an explicit names=None works)

[TomAugspurger]

@christopherzimmerman do you have time to make names=None mean "no names for any levels"?

The default value will be something like

_no_default = object()

def from_product(self, ..., names=_no_default, ...):
    if names is None or names is _no_default:
        names = [None] * nlevels

[christopherzimmerman]

@TomAugspurger sorry for the inactivity, I'll make those changes. I believe I messed up the commit history for this PR when I rebased from master (which is resulting in a check failing), and have a lot of junk commits included, I may close this PR and open another one.