Deprecate Series.strides, .base, .data, .itemsize, .flags (numpy) attributes ?

[jorisvandenbossche]

Related to #18262, but since this is a very specific class of attributes, thought to open a specific issue about it.

We have a bunch of attributes on the Series class that stem from the time it was a numpy array subclass, and now just pass through the attribute of the underlying numpy array. It are typically attributes describing the data layout specific to the numpy array, which I don't think necessarily makes sense for a Series:

• Series.base
• Series.data
• Series.strides
• Series.itemsize
• Series.flags

and potentially also:

• Series.real and Series.imag

So deprecating those can potentially remove 7 entries from the Series namespace.

Are there good reasons to keep them? Is this somehow useful for "compatibility" (writing code that works for both series as numpy array)
(I personally can't think of a usecase where you would want one of the above, unless you explicitly know will deal with numpy arrays)

One of the problems might be that if we refer users to Series.values.<attribute> that this will depend on the underlying array type if that will work or not (eg if .values starts giving an ExtensionArray, it will also not have those attributes)

cc @shoyer I don't think you kept those for "compatibility" in DataArray in xarray?
And in dask I think itemsize, real and imag is provided.

[shoyer]

In xarray we have real/imag but all these other low level NumPy attributes are dropped (.data means something else entirely). I agree with deprecating these for Series.

[jorisvandenbossche]

What are people's feeling about imag and real? They were added back explicitly (#4819) after they disappeared with the Series refactor (for backwards compatibility).

[TomAugspurger]

I'm fine with keeping real and imag.

[RubenAstudillo]

I am hitting the deprecation warning on using the .data parameter which doesn't tell me the right path on where to look at for operating on the array (I needed to do boxcox on it, but the index were of no use). Maybe adding a hint towards Series.values.data? maybe a link on why shouldn't I use .data?

[jgerity]

It also looks like this planned deprecation is not mentioned in the docs, and definitely should be if it's raising FutureWarning

[jreback]

this was deprecated several versions ago

[jorisvandenbossche]

Maybe adding a hint towards Series.values.data? maybe a link on why shouldn't I use .data?

Series.values is also not guaranteed to return a numpy array (eg for categoricals), so np.asarray(Series).data might be more reliable (although for the cases Series.values is not a numpy array, that method will also point to the data of a copy ..).

May I ask why you need .data to do boxcox on it? I would think you just need the numpy array to ignore the index?

It also looks like this planned deprecation is not mentioned in the docs, and definitely should be if it's raising FutureWarning

That's a good point! PR to add this to the docstrings very welcome.

[RubenAstudillo]

Yeah, it was not the most straight forward way to do boxcox. It was still confusing.