Skip to content
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

API: expose to_numeric/to_datetime/to_timedelta methods on Series #15550

Closed
jreback opened this issue Mar 2, 2017 · 5 comments
Closed

API: expose to_numeric/to_datetime/to_timedelta methods on Series #15550

jreback opened this issue Mar 2, 2017 · 5 comments
Labels
Closing Candidate May be closeable, needs more eyeballs Enhancement Needs Discussion Requires discussion from core team before further action

Comments

@jreback
Copy link
Contributor

jreback commented Mar 2, 2017

if we have a string Series, e.g. s = Series(['2013-01-02', '2013-1-03'])

we normally just run this thru pd.to_datetime(s)

it might be convenient to do these operations (.to_numeric,.to_datetime,.to_timedelta)
directly as methods.

  • s.str.to_numeric(....) , IOW in the .str namespace
  • s.to_numeric(...), in main Series namespace
  • s.astype(.., dtype=...) but actually pass thru to using the .to_numeric/.to_datetime functions directly, so you could have something like
    s.astype('datetime', format='%Y-%m-%d') and it would do the right thing. This overloads things a bit though

right now we have a bit of confusion because we support .astype which is pretty much a pass thru to numpy, and the more dtype-aware (and functional) .to_* ones.

Furthermore I think we could update the .astype docs (and the .to_*) ones to cross reference.

@jreback jreback added API Design Needs Discussion Requires discussion from core team before further action labels Mar 2, 2017
@chris-b1
Copy link
Contributor

chris-b1 commented Mar 3, 2017

I was thinking this would be nice the other day. Don't want to get too carried away with the accesssors, but what about a .type (may be a better name) one to stuff these into?

s.type.astype(...) # numpy style
s.type.to_datetime(...)`
# maybe add?
s.type.to_category(...)

In general the current astype(...) / to_datetime(...) difference is a bit confusing.

@jreback jreback changed the title API: expose to_* methods on Series API: expose to_numeric/to_datetime/to_timedelta methods on Series Mar 27, 2017
@kernc
Copy link
Contributor

kernc commented May 25, 2017

+1 for simply overloading .astype(..., **kwargs) with kwargs passed to expecting functions. 👍

@topper-123
Copy link
Contributor

I like @chris-b1 's idea, but I suggest the accessor be called .cast instead, because
IMO the name type can be confused with .dtype. So:

  • s.cast.to_type,
  • s.cast.to_datetime,
  • etc.

I'm +1 on overloading .astype, i.e. making astype delegate to various subfunction depending on input. That would of course require a upgrade to the docs to avoid confusion.

I'm -1 on adding the functionality to dataframe/series namespace (e.g. s.to_datetime) as I think the API is already very large and we need to group similar functionality together to lessen the cognitive load of knowing the library.

@tdpetrou
Copy link
Contributor

Bump!
The **kwargs are available in astype but apparently, they don't work for certain dtypes? The docstrings even mention the kwargs get passed to the constructor but this isn't happening for datetime64. And what is the constructor for datetime64? Is it to_datetime or Timestamp?

@jbrockmendel jbrockmendel added the Closing Candidate May be closeable, needs more eyeballs label Jan 23, 2023
@mroeschke
Copy link
Member

Looks like there's not much appetite to putting these methods on Series so closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closing Candidate May be closeable, needs more eyeballs Enhancement Needs Discussion Requires discussion from core team before further action
Projects
None yet
Development

No branches or pull requests

7 participants