Is it necessary to unify pandas and pd in docstring?

[icyblade]

There are two kinds of demonstration of pandas in current docstring, pandas. and pd..

For example, pd.:

msg = ('cannot concatenate object of type "{0}";'
       ' only pd.Series, pd.DataFrame, and pd.Panel'
       ' (deprecated) objs are valid'.format(type(obj)))

and pandas.:

warnings.warn("The pandas.json module is deprecated and will be "
              "removed in a future version. Please import from "
              "pandas.io.json instead", FutureWarning, stacklevel=2)

pd. is friendly to experienced pandas users, but it may lead to misunderstanding for newbies(no offence).
So is it necessary to unify these two presentations?

I'd like to create a PR if it's necessary.

[WillAyd]

Fair question but I don't think the two examples are apples to apples. The former is dealing with API exposed objects whereas the second example is referring to the import path of a particular module. I'd say these are both correct as is.

Do you see any instances where API-exposed objects are being namespaced with pandas instead of pd? Those may be worth updating.

[icyblade]

For example, this code:

the user provides a pandas.Series object of the same length as the data

[jorisvandenbossche]

In that specific case, just 'Series' instead of 'pandas.Series' would also be just fine. But, it's in a private docstring, and also not that important.

During the documentation sprint we had some cases where it was not always clear when to use pandas. and when not, but that problem is covered in #20309