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

apply on np.datetime col doesn't upconvert to Timestamp #2627

Closed
dalejung opened this issue Jan 2, 2013 · 9 comments
Closed

apply on np.datetime col doesn't upconvert to Timestamp #2627

dalejung opened this issue Jan 2, 2013 · 9 comments
Assignees
Labels
Bug Datetime Datetime data dtype
Milestone

Comments

@dalejung
Copy link
Contributor

dalejung commented Jan 2, 2013

import pandas as pd

s = pd.Series(pd.date_range(start="2000/1/1", freq="D", periods=10))
s.apply(lambda x: x.date())

# AttributeError: 'numpy.datetime64' object has no attribute 'date'

This is an error from some unit tests. Did something major change with how datetimes are handled? I recall that np.datetime64 was autoboxed into Timestamps.

I'll update after poking around.

@dalejung
Copy link
Contributor Author

dalejung commented Jan 2, 2013

Ah, I'm a liar. The unit test was more like

ind = pd.date_range(start="2000/1/1", freq="D", periods=10)
vals = [pd.Timestamp(str(d)) for d in ind]
df = pd.DataFrame(index=ind)
df['dates'] = vals
df.dates.apply(lambda x: x.date())

Which worked on 0.10.0 since it kept the objects around.

@dalejung
Copy link
Contributor Author

dalejung commented Jan 2, 2013

e06334a

Found the commit. Makes sense, I'll change stuff on my end. Perhaps this should be an enhancement?

@jreback
Copy link
Contributor

jreback commented Jan 2, 2013

yes should be a mention in release notes
(it's more of a partial bug fix actually)
not sure that it always converts to time stamps, just more often
eg see applymap in frame.py (had to force conversion here, not sure of the promises that pandas makes in regards to whether the object is a time stamp (or a np.datetime64)
prob a number cases that are not well tested

@dalejung
Copy link
Contributor Author

dalejung commented Jan 2, 2013

Yeah. It broke a couple things on my end. There should probably be more emphasis on the change since it breaks things in indirect ways.

@jreback
Copy link
Contributor

jreback commented Jan 2, 2013

do u have an example of something that works on 0.10.0 and breaks in master?

@dalejung
Copy link
Contributor Author

dalejung commented Jan 2, 2013

see my first comment. Anything that assumes the DataFrame columns will stay objects and thus have object methods available.

@jreback
Copy link
Contributor

jreback commented Jan 3, 2013

your example fails in 0.10.0 as well, did this work in a previous version?

(as a side note, your example is a series; frames I believe work correctly)

interestingly this works:

for x in s:
    s.date()

as s is the correct type 'M8[ns]', and the iteration does on-the-fly conversion to Timestamp...simple to fix apply to do that (as was done with applymap in Frame)....but bigger question is that this conversion could be done in the constructor. maybe performance related? and/or since we are talking about a column of data (and not the index), its very hard to explicty infer the correct type (and you also want to allow somewhat arbitrary types in the container as well). The user I think should force the conversion (which is the way it is now)

@wesm any thoughts here?

@dalejung
Copy link
Contributor Author

dalejung commented Jan 3, 2013

I think you misread my comment. The original post never worked. At the time, I hadn't realized that the issue was the object -> datetime64 conversion. Without the conversion, auto-boxing is not necessary.

I was referring to the DataFrame example which does work in 0.10.0. Also, creating a Series out of a list of object doesn't convert to datetime64 in dev. So there's a lack of consistency there.

I'm ambivalent to whether automatic object -> datetime64 is correct. It's more of a backwards compatibility issue.
#2624 also came up for me due to the change.

@wesm wesm closed this as completed in 6ffef16 Jan 20, 2013
@ghost ghost assigned wesm Jan 20, 2013
@wesm
Copy link
Member

wesm commented Jan 20, 2013

fixed this thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Datetime Datetime data dtype
Projects
None yet
Development

No branches or pull requests

3 participants