Inconsistent handling of .item with PeriodIndex

[max-sixty]

Is this an inconsistency?

With DatetimeIndex, .item() gets the item, and .data gets a 0-d array:

In [14]: da=xr.DataArray(pd.DataFrame(pd.np.random.rand(10), index=pd.DatetimeIndex(start='2000', periods=10,freq='A')))

In [15]: p=da['dim_0'][0]

In [16]: p.values
Out[16]: numpy.datetime64('2000-12-31T00:00:00.000000000')

In [17]: p.item()
Out[17]: 978220800000000000L

But with a PeriodIndex, values gets the item, and so .item() fails

In [22]: da=xr.DataArray(pd.DataFrame(pd.np.random.rand(10), index=pd.PeriodIndex(start='2000', periods=10)))

In [23]: p=da['dim_0'][0]

In [24]: p.values
Out[24]: Period('2000', 'A-DEC')

In [25]: p.item()
AttributeError: 'pandas._period.Period' object has no attribute 'item'

[shoyer]

Actually, p.values in your first example is a datetime64 scalar. NumPy scalars support .item(), though.

So I think one reasonable approach would be to implement .item() for pandas.Period, too. One difference is that there is no native Python scalar for periods, so I would probably just make .item() a no-op.

Side note: that the behavior you show for DatetimeIndex/datetime64[ns] is actually a bug in NumPy related to nanosecond precision:

In [4]: np.array(np.datetime64('2000-01-01', 'us')).item()
Out[4]: datetime.datetime(2000, 1, 1, 0, 0)

In [5]: np.array(np.datetime64('2000-01-01', 's')).item()
Out[5]: datetime.datetime(2000, 1, 1, 0, 0)

In [6]: np.array(np.datetime64('2000-01-01', 'ns')).item()
Out[6]: 946684800000000000

It's probably worth filing on bug report, if one doesn't already exist...

[max-sixty]

So I think one reasonable approach would be to implement .item() for pandas.Period, too.

I see, because all numpy dtypes have .item(), and Period is trying to be a dtype? I haven't come across .item() before but I generally don't work much with numpy directly

[shoyer]

I see, because all numpy dtypes have .item(), and Period is trying to be a dtype? I haven't come across .item() before but I generally don't work much with numpy directly

Yes, that would be the argument here. It's not clear how closely pandas should be mimicking NumPy here, though, given that we are looking to eventually make the backend flexible enough that it doesn't need to be built on NumPy.

[max-sixty]

OK great. Closing this. Cheers