DISC/DES: EA should have transpose, T, ravel mirroring ndarray/Index/Series

[jbrockmendel]

As long as EA is 1D only these are all no-ops, so implementation is trivial. It would save a bunch of special-casing and checking for exactly what type of object we have at different stages.

The cost is API clutter.

I'm of the opinion that EA should be as close as possible to a drop-in replacement for ndarray, (both for our purposes and so it can be useful in the ecosystem), so we should implement these properties/methods.

Last I heard @TomAugspurger came down on the less-clutter side of this question. Anyone else have an opinion?

[jreback]

I am with @jbrockmendel here. There is no point in not having the methods / properties, only to have to special case / work-around (in a myriad of ways) in various parts of the codebase. This is a huge complexity internally.

A few extra properties / methods IMHO is so worth it here.

[TomAugspurger]

I'd prefer to hold off on adding methods that are unnecessary for 1-D arrays. I don't want to burden users with them.

What do you mean by API clutter? Isn't avoiding clutter the benefit?

@jorisvandenbossche might have an opinion.

[jorisvandenbossche]

I also prefer that we take the conservative route in this light: only add methods when we (or downstream) actually have a good use case for them.

This is a huge complexity internally.

Can you give some examples where this currently creates complexity? In the BlockManager?

[jreback]

• Block._astype is a mess
• Block.where is not able to be sublcassed
• DatetimeBlock and DatetimeTZBlock cannot combine more code
• ObjectBlock.convert

lots of reshaping issues that were recently added in #24024

This is just adding complexity for no reason. If we have an array class then it needs to be almost a drop in for numpy arrays. Not having basic reshaping is causes lots of headaches.