DEPR: special-casing dt64/td64 in Series.unique

[jbrockmendel]

• closes #xxxx
• tests added / passed
• Ensure all linting tests pass, see here for how to run them
• whatsnew entry

dti = pd.date_range('2016-01-01', periods=3).repeat(2)
ser = pd.Series(dti)

>>> ser.unique()
<stdin>:1: FutureWarning: Series.unique behavior with datetime64[ns] dtype is deprecated. In a future version this will return a <class 'pandas.core.arrays.datetimes.DatetimeArray'> instead of a np.ndarray
array(['2016-01-01T00:00:00.000000000', '2016-01-02T00:00:00.000000000',
       '2016-01-03T00:00:00.000000000'], dtype='datetime64[ns]')

[jreback]

can you add a release note. IIUC this will always warn? how does one avoid this?

[jbrockmendel]

IIUC this will always warn? how does one avoid this?

i guess could do ._values.unique

[jreback]

i am confused over when the user would see this, can you update the top of the PR

[jbrockmendel]

added example to OP

[jreback]

so the problem is this will always warn right?

[jbrockmendel]

yah, i guess could do it without deprecation in 2.0

…

On Sat, Aug 7, 2021 at 4:45 PM Jeff Reback ***@***.***> wrote: so the problem is this will *always* warn right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42741 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5UM6HI7OJSRP5YVDP2SUTT3XAS3ANCNFSM5BBBDEUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[github-actions]

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

[jreback]

@jbrockmendel worth fixing this up?

[jbrockmendel]

worth fixing this up?

i think this is worth doing. IIRC the trouble was that if we issue a FutureWarning, we don't have a good way to say "do X instead to get the future behavior". Best idea ATM is to just make the change in 2.0 without a deprecation cycle.

[jreback]

yeah sounds good to me

[jreback]

@jbrockmendel this for 2.0? if so let's just close it (and add to the list itself which i think you did)

[jbrockmendel]

this for 2.0? if so let's just close it (and add to the list itself which i think you did)

sure.