@charris : +1 for the Discussion label - I would love to hear other people's opinion about this!

I think it makes sense to return the numpy type if the dtype keyword was specified.

To preserve backwards compatibility with 1.10 we could still return a Python int if neither size nor dtype are specified, I suppose. But that sounds like an extra complication that will almost never affect anyone, and if users know randint returns arrays of np.int64 by default, they will not be surprised to get an np.int64 when size=1 too.

What is the test error you get in diophantine_fuzz? I don't get it on my system after removing the cast to int.

Big kudos to you and @charris by the way for all the improvements to the np.random dtype argument!

@ahaldane : Thank you! Though I think @charris should get extra big kudos since he was the first person to successfully implement it into the codebase 😄

I agree that backwards compatibility need not necessarily be preserved in such a case since I would imagine the most common use case is to generate arrays of data. Also, as the dtype parameter has not even been officially released yet, the impact stands to be minor IMHO.

Regarding the test failures, the tests fail, at least locally, due to warnings about scalar overflow because they're now Numpy integers and not Python integers.

Added the 1.11.0 milestone since, if this goes in, we might as well start right :)

Is there anything else people would like to add with regards to this change? Otherwise, it should be good to merge.

I was still a little worried about the unit test you modified, but I convinced myself it's OK. That test is hardcoded in C to expect a Python int for some reason, so it's not a more general problem in numpy.

I'll merge in a few hours if there are no more comments.

@ahaldane : Thanks for taking the time to look at several of my PR's!

Thanks @gfyoung