I think it would make sense to also do this fornp.integer:

>>>float.__trunc__<method '__trunc__' of 'float' objects>>>>int.__trunc__<method '__trunc__' of 'int' objects>

The other rounding dunders are currently also present in bothfloating andinteger.
Thoughts?

the type-test atnumpy/typing/tests/data/fail/scalars.pyi:86 should be removed now

I think it would make sense to also do this for np.integer:

Oh for sure, since the implementation is small, I'll squeeze it in here. Thanks for the info!

the type-test at numpy/typing/tests/data/fail/scalars.pyi:86 should be removed now

Ah that makes sense.

@jorenham a basic query on integer's typing: How did it get added? There is no diff indicating it's added:

Help on method_descriptor:__trunc__(self, /) unbound numpy.integer method    int8.__trunc__() -> int

@jorenham a basic query on integer's typing: How did it get added? There is no diff indicating it's added:

Help on method_descriptor:__trunc__(self, /) unbound numpy.integer method    int8.__trunc__() -> int

I'm not sure I understand you question. Are you asking how to verify that the method you added in the stubs actually works? Because if so, you could do that by adding a type-test intyping/tests/data/pass.

you could do that by adding a type-test in typing/tests/data/pass

Ah ok, got it. I was actually curious on how the typing for int.trunc got added to begin with. There is no change in int typing, but yet, it got added.