Probably from #11324; cc @eric-wieser.

I think your example is proof that it silently ignored the byte order, not that it "worked". The current implementation is more honest in stating that nonnative byte order is not supported.

For example,

np.random.seed(0)
a = np.random.randint(256,dtype='u1',size=4)
np.random.seed(0)
b = np.random.randint(256**4, dtype='u4', size=1)
np.random.seed(0)
c = np.random.randint(256**4, dtype='>u4', size=1)
np.random.seed(0)
d = np.random.randint(256**4, dtype='<u4', size=1)
print(a.view('<u4'), b, c, a.view('>u4'), d)

[2357136044] [2357136044] [2357136044] [2886369164] [2357136044]

It is worked, then the final 2 values would be identical.

@bashtage is right, the order was ignored

>>> np.random.randint(0, 200, size=10, dtype='>i4').dtype.byteorder
'='
>>> np.random.randint(0, 200, size=10, dtype='<i4').dtype.byteorder
'='

However, this seems pretty par-for-the-course for numpy:

>>> np.add(1, 2, dtype='>i4').dtype.byteorder
'='
>>> np.add(1, 2, dtype='<i4').dtype.byteorder
'='

I think a patch that explicitly discards the byteorder (via newbyteorder('=')) before doing the dictionary lookup would be fine.

It is worked, then the final 2 values would be identical.

@bashtage you are correct that byteorder is ignored, but this check is not correct. That is not the behaviour that's desired, nor is it consistent with other creation functions. Specifying byteorder does not change values, it changes storage. It's clearer to compare the result of .tobytes:

In [2]: np.ones(3, dtype='>i4').tobytes()
Out[2]: b'\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01'

In [3]: np.ones(3, dtype='<i4').tobytes()
Out[3]: b'\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00'

vs

In [8]: np.random.seed(0); np.random.randint(200, size=10, dtype='>i4').tobytes()
Out[8]: b'\xac\x00\x00\x00/\x00\x00\x00u\x00\x00\x00\xc0\x00\x00\x00C\x00\x00\x00\xc3\x00\x00\x00g\x00\x00\x00\t\x00\x00\x00\x15\x00\x00\x00$\x00\x00\x00'

In [9]: np.random.seed(0); np.random.randint(200, size=10, dtype='<i4').tobytes()
Out[9]: b'\xac\x00\x00\x00/\x00\x00\x00u\x00\x00\x00\xc0\x00\x00\x00C\x00\x00\x00\xc3\x00\x00\x00g\x00\x00\x00\t\x00\x00\x00\x15\x00\x00\x00$\x00\x00\x00'

Ping to everyone :)

We could argue that it should go through deprecation before going to raise (I think raise is probably slightly better then silent ignoring), but I am not sure this is a big enough issue to worry much. Of course it would also be good to allow non-native order.

This is a patch in mattip#36 that produces a FutureWarning on this. It isn't a bug in the randomgen branch and would have silently run without doing any byte swapping. IMO it is better to leave this to users rather than push a .byteswap down into the function. The warning says as much.