-
-
Notifications
You must be signed in to change notification settings - Fork 18.2k
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
Comments
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 s.type.astype(...) # numpy style
s.type.to_datetime(...)`
# maybe add?
s.type.to_category(...) In general the current |
+1 for simply overloading |
I like @chris-b1 's idea, but I suggest the accessor be called
I'm +1 on overloading I'm -1 on adding the functionality to dataframe/series namespace (e.g. |
Bump! |
Looks like there's not much appetite to putting these methods on Series so closing |
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
namespaces.to_numeric(...)
, in main Series namespaces.astype(.., dtype=...)
but actually pass thru to using the.to_numeric/.to_datetime
functions directly, so you could have something likes.astype('datetime', format='%Y-%m-%d')
and it would do the right thing. This overloads things a bit thoughright 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.The text was updated successfully, but these errors were encountered: