ER: should constructors check and raise if big-endian dtypes are detected?

[jreback]

related #2330, #2821

pretty easy to do; doesn't really take much time either (can be done in the block manager)

http://stackoverflow.com/questions/18599579/python-pandas-multi-index

could also easily convert them (which in theory could be expensive so should be a method)

[shoyer]

This seems to come up with some frequency when dealing with data converted from binary file formats like FITS or netCDF.

I think we should definitely handle this automatically -- or provide some sort of constructor that allows for opting in to handling this automatically. It's not very user friendly to need to manually check types and do a byteswap before passing data in.

CC @astrofrog

[embray]

I agree--I don't see the big deal to doing this automatically (except that it's not that common a case for most users and so working on a patch for this would be low priority which I can certainly relate to ;)

[elehcim]

Any news on this?

[jreback]

@elehcim pandas would accept a community pull request

core can provide review

[musicinmybrain]

Does this imply that Pandas would like to support only little-endian hosts and little-endian data?

On Fedora Linux, big-endian s390x is a primary architecture. I’ve been working to incrementally update the package and to start running the tests in the RPM build, and at least for Pandas 1.3.5, all but a few of the tests currently do pass on s390x. I probably shouldn’t bother with a PR to improve the endian-independence of the tests if big-endian platforms are going to be explicitly excluded…

[jreback]

would accept patches for big end ian

but we have 0 testing so cant officially support