Skip to content

pandas.Series docstrings dtype information #24325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DanielGoldfarb opened this issue Dec 17, 2018 · 6 comments · Fixed by #24421
Closed

pandas.Series docstrings dtype information #24325

DanielGoldfarb opened this issue Dec 17, 2018 · 6 comments · Fixed by #24421
Labels
Docs Dtype Conversions Unexpected or buggy dtype conversions
Milestone

Comments

@DanielGoldfarb
Copy link

docstring for pandas.Series states:

dtype : numpy.dtype or None
    If None, dtype will be inferred

I'm new at this so I don't know all the dtypes that are valid, but at the very least I see that I can write dtype='category' yet categorical_dtype is (as far as I know) not a numpy.dtype (or am I missing something?)

Assuming I'm correct, that there is at least one (possibly more) valid input(s) for dtype that are NOT numpy.dtypes (and not None), then it would be nice if all of them could be listed here. If someone can point me in the right direction (where to gather valid dtype inputs) I would be happy to make the docstring change myself and enter a PR.

@TomAugspurger
Copy link
Contributor

This has changed on master:

dtype : str, numpy.dtype, or ExtensionDtype, optional
dtype for the output Series. If not specified, this will be
inferred from `data`.

Does that clarify things? I think the main thing that's missing is a link to our dtypes reference at

:ref:`basics.dtypes`

You're correct that category is not a NumPy dtype. It's an extension dtype.

Listing them all probably isn't a good idea, especially since third parties can add additional extension dtypes that would be valid here.

@DanielGoldfarb
Copy link
Author

DanielGoldfarb commented Dec 18, 2018

That change makes it somewhat more clear, and I agree that if the list is long, then listing them in the docstring is probably not a good idea. A link in the docstring would be appropriate, however I don't understand exactly where

:ref:basics.dtypes

is supposed to be pointing me. Also, in the case of 'str', I would hope the link would point to a place that lists all possible valid strings that a client of the constructor can use.

@DanielGoldfarb
Copy link
Author

Was the intention to link to here?

https://pandas.pydata.org/pandas-docs/stable/basics.html#dtypes

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Dec 18, 2018 via email

@DanielGoldfarb
Copy link
Author

Understood regarding using :ref: version; I guess being a newbie to python and pandas, I didn't quite understand the syntax

:ref:`basics.dtypes`

and what it's supposed to mean: it took me more than a couple minutes of poking around to find https://pandas.pydata.org/pandas-docs/stable/basics.html#dtypes

And now that I think of it, I'm a little confused regarding the syntax meaning of saying

dtype : str, numpy.dtype, or ExtensionDtype, ...

in that I now realize (correct me if I'm wrong) that when specifying the optional dtype (keyword) argument, the value will actually always be a string such as

dtype='category'
dtype='int64'
dtype='str'

Is the 3rd one (dtype='str') what is actually meant by the 'str' in

dtype : str, numpy.dtype, or ExtensionDtype, ...

or did you mean something else??

Apologies if these questions sound stupid. Still trying to get used to some of the short-hand ways of speaking within the python documentation.

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Dec 18, 2018 via email

@jreback jreback added the Dtype Conversions Unexpected or buggy dtype conversions label Dec 25, 2018
@jreback jreback added this to the 0.24.0 milestone Dec 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Docs Dtype Conversions Unexpected or buggy dtype conversions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants