[Michael Seifert]
> I'm not sure if there are many use-cases where numpy scalars
> make sense as inputs for `islice`

Likewise, I'm not sure there is any evidence of a use-case.  The incompatible relationship between numpy ints and PyLong_AsSsize_t() has been around for a long time and no one seems to have even noticed until now.

Also, you're right that the error message isn't very helpful unless you already understand that np.int32 isn't a subclass of int.

[Serhiy]
> Adding support of more general int-like objects in islice() 
>looks reasonable to me.

Conceptually, anything with an __index__ method might make sense in the context of slicing, so the proposal doesn't sound unreasonable on the face of it.

Practically though, there doesn't seem to be any evidence of a real use case here.  It is unclear whether allowing np.int32 would ever benefit anyone and whether dropping the current requirement for an explicit int() cast would encourage weird and inefficient code.

Either way, this should be categorized as a feature request.  CPython itself is passing tests and isn't breaking any promises.

[Will Roberts]
> Note that this issue also seems to affect other methods 
> in the itertools package, such as permutations.

If we do make some sort of change, it should be limited it to just islice().  To me, this only makes sense in the context of index arguments unless someone makes a broad and consequential executive decision that everything in Python that accepts an integer needs to also check for int-like objects as well.