I don’t think changing the astype implementation is correct, instead we should do a try/except (or the equivalent in C if the the getattr is happening in C) and raise the appropriate error at the site where it happens.

Generally it’s best to open issues about bugs you find before sending in a PR with a fix, particularly for projects you’re new to the internals of.

I don’t think changing the astype implementation is correct, instead we should do a try/except (or the equivalent in C if the the getattr is happening in C) and raise the appropriate error at the site where it happens.

Generally it’s best to open issues about bugs you find before sending in a PR with a fix, particularly for projects you’re new to the internals of.

So, should i do smt like this:

    if not (isinstance(x, np.ndarray) or isscalar(x)):
        raise TypeError(
            "Input should be a NumPy array or scalar. "
            f"It is a {type(x)} instead."
        )
    if device is not None and device != "cpu":
        raise ValueError(
            'Device not understood. Only "cpu" is allowed, but received:'
            f' {device}'
        )
    try:
        return x.astype(dtype, copy=copy)
    except AttributeError:
        raise TypeError(
            "Input should be a NumPy array or scalar."
            f"It is a {type(x)} instead. Python scalars are not supported. "
        )

I don’t think changing the astype implementation is correct, instead we should do a try/except (or the equivalent in C if the the getattr is happening in C) and raise the appropriate error at the site where it happens.

Generally it’s best to open issues about bugs you find before sending in a PR with a fix, particularly for projects you’re new to the internals of.

Also, if I did everything correctly, it will only omit the python native scalars, returning proper error, which is what the previous reviewer asked for in the other PR, where I implemented python-native scalar handling(here's link to that PR: #31365 )

I don’t think changing the astype implementation is correct, instead we should do a try/except (or the equivalent in C if the the getattr is happening in C) and raise the appropriate error at the site where it happens.

Generally it’s best to open issues about bugs you find before sending in a PR with a fix, particularly for projects you’re new to the internals of.

ok, i've changed the way it handles attribute error to try_except