scalar does not inherit byteorder from the array it's "created" from (Trac #1268)

[thouis]

Original ticket http://projects.scipy.org/numpy/ticket/1268 on 2009-10-20 by @mdboom, assigned to unknown.

In [9]: x = np.array([1], dtype='<i4')

In [10]: x[0].dtype.byteorder
Out[10]: '='

In [11]: x = np.array([1], dtype='>i4')

In [12]: x[0].dtype.byteorder
Out[12]: '='

This may in fact be correct behavior, but it can lead to confusing use of byteswap, since the following is not guaranteed:

x.byteswap().tostring() == x[0].byteswap().tostring()

and for that matter, neither is:

x.tostring() == x[0].tostring()

(This bug began as part of #1857, but is probably a different bug.)

[thouis]

@pv wrote on 2010-10-10

It seems (cf. arrayscalars.h) that the scalar objects do not even have byte order on the C level, they're just assumed to be native.

[thouis]

Milestone changed to Unscheduled by @pv on 2010-10-10

[jnothman]

I have just been bitten by this in a context where I wanted to play with bits. Another example:

>>> np.unpackbits(np.array([9999], dtype='>u4').view('u1'))
array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1,
       1, 0, 0, 0, 0, 1, 1, 1, 1], dtype=uint8)
>>> np.unpackbits(np.atleast_1d(np.array([9999], dtype='>u4')[0]).view('u1'))
array([0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0], dtype=uint8)

I think this behaviour needs to be documented at http://docs.scipy.org/doc/numpy/user/basics.byteswapping.html

EDIT (@seberg): The above documentation note has been added in the meantime.

[mattip]

Turning this into a documentation issue.

Edit: we will not change behaviour, but we should document it.

[melissawm]

Can anyone (@seberg?) either help me find the original ticket (now showing a 404) or figuring out what to document? Thanks!

[seberg]

@melissawm the original ticket only has the same information as shown here AFAIK (I think the track is lost in time, at least I do not know who might still have the data).

There is a warning here now: https://numpy.org/doc/stable/user/basics.byteswapping.html (a bit down the page). Maybe that is just enough? Scalars are always stored as native-byteorder, so indexing, etc. can "swap" if the result is a scalar. OTOH, also ufuncs never "preserve" byte-order, so losing the byte-order information is not that uncommon anyway.

We could probably drop the "currently", I don't really see this changing any time soon (there is probably semi-public API that would even break, anyway).