Not sure we should do this, since this function really exists only for the Array API, I would say, so I am not sure there is a reason to broaden it up beyond such use.

Not sure we should do this, since this function really exists only for the Array API, I would say, so I am not sure there is a reason to broaden it up beyond such use.

but still, it may be an issue?

To me it isn't an issue until someone asks from it from a usability perspective outside of the original context. But if other maintainers prefer to do coerction to array here because NumPy usually does, sure...

To me it isn't an issue until someone asks from it from a usability perspective outside of the original context. But if other maintainers prefer to do coerction to array here because NumPy usually does, sure...

That makes sense, and i also don't think anyone would often use this outside of what it is intended for.
How about returning a typeError(like for the rest issues) if the python int is passed, instead of attributeError?

(raise TypeError(
"Input should be a NumPy array or scalar. "
f"It is a {type(x)} instead."
))

To me it isn't an issue until someone asks from it from a usability perspective outside of the original context.

I agree. In the stubs it's even stricter currently, because it only accepts ndarray, so no scalars at all:

How about returning a typeError(like for the rest issues) if the python int is passed, instead of attributeError?

Sounds good to me

To me it isn't an issue until someone asks from it from a usability perspective outside of the original context.

I agree. In the stubs it's even stricter currently, because it only accepts ndarray, so no scalars at all:

numpy/numpy/_core/numeric.pyi

Lines 1349 to 1366 in 5cba3b4

	@overload
	def astype[ShapeT: _Shape, ScalarT: np.generic](
	x: ndarray[ShapeT],
	dtype: _DTypeLike[ScalarT],
	/,
	*,
	copy: py_bool = True,
	device: L["cpu"] | None = None,
	) -> ndarray[ShapeT, dtype[ScalarT]]: ...
	@overload
	def astype[ShapeT: _Shape](
	x: ndarray[ShapeT],
	dtype: DTypeLike | None,
	/,
	*,
	copy: py_bool = True,
	device: L["cpu"] | None = None,
	) -> ndarray[ShapeT]: ...

How about returning a typeError(like for the rest issues) if the python int is passed, instead of attributeError?

Sounds good to me

So, should I create a new branch/PR, where the code will return attribute error for python-native numbers, or should I make changes on this one?

So, should I create a new branch/PR, where the code will return attribute error for python-native numbers, or should I make changes on this one?

Whatever you prefer

ok, i will create a new branch with PR