This is getting very tedious and opaque in the intp as default PR. The test are failing here though, would be great to get some of these fixes out of the way to hopefully get somewhere in that PR.
I thinkt he fix here is just that the numerictypes reveal test also needs changing.

@BvB93 moving this over here for now. For some reason, I have to use pytest.mark.slow = lambda x: x to get things to run, but whatever.

The big churn here, is that randint/integers was typed incorrectly. We return int/bool only if dtype is exactly that (the code is a bit unclear, I fixed that also).

Ideally, this should make it much easier to make progress on the other PR once finished. Locally, the tests were passing, but of course I am not 100% sure that will translate to windows.

Btw. I am a bit surprised, but the reveal tests don't actually check that the revealed type matches the run-time result? Because the random ones were never actually correct here.

OK, mypy tests are passing. I would like to finally unblock gh-24224, so would appreciate a review.

Currently looking at #24224 as well; turns out an _ULongCodes and _LongCodes import is missing from ctypeslib.pyi but there are also some issues with getting ctypes.c_long vs ctypes.c_int return types right (including their unsigned version). The latter in particular is more of an annoyance rather than an actual issue, so you might want to disable those tests for the time being.

issues with getting ctypes.c_long vs ctypes.c_int return types right

Yeah, I thought reordering things might help with that one, but I am not sure it is a reasonable thing and just returning to the old platform dependent version seems OK also.

Yeah, I thought reordering things might help with that one, but I am not sure it is a reasonable thing and just returning to the old platform dependent version seems OK also.

Either is fine tbh, as long as it just stops blocking your PR as the typing failures have been a hold up for long enough now IMO.

Btw. I am a bit surprised, but the reveal tests don't actually check that the revealed type matches the run-time result? Because the random ones were never actually correct here.

Just a bit more context: the reveal type tests check, using typing.assert_type, that an expressions return type matches the return type as is inferred by a type checker; it does not involve any actual runtime checks (the latter in particular would get very tricky once parametrized types such as NDArray[int64] are involved, as the interpretation of the parameter is entirely up to the parametrized types. It can represent the an element-/data-type, an attribute type, something more abstract, etc.. It's not too difficult to infer its meaning for a single specific type (or set thereof), but doing so in a general way is highly challenging if not impossible).

@BvB93 do you want to have a closer look at this? Otherwise, I am tempted to push things through and consider it a follow-up review.

Let's pull this in to unblock changing the default integer on windows.