add check for endianess in major constructors
apropos #2318

This should probably get put in a Cython function that uses the NumPy C API before it can ship. The additional overhead (a couple microseconds is significant) is more concerning in the Series constructor than DataFrame
 fwiw The relevant vbenchmark is series_constructor_ndarray
 No problem, I can do that. is it worth it or is this a non-issue?
 It does seem potentially like overkill since the mixed-endianness problem I would expect to be very rare in practice. Hmm
 your call, i'll leave this open for now. let me know either way (or just close).
 how significant of a performance regression is it?
a possible place where this can happen in practice is when dealing with fits files [1].
fits stores its data in big endian format and it is not unusual to just memory map that in with numpy.

[1] http://fits.gsfc.nasa.gov/
 Tabling this til a later time. I did a brief tinker with some big-endian arrays and it's not clear to me where problems might arise-- DataFrame for example casts any input data to little-endian on arrival, though all that conversion might be a bad thing with large data sets. There's a lot of work needing to be done on data type handling in the near future, so it would be good to make a battery of "smoke tests" to ensure responsible handling of big-endian data types. 
 This will never get merged. closing. left #2821 as future reminder.
