raise error with unsupported types in check_type

[martinResearch]

Is your feature request related to a problem? Please describe.

I have been making errors of the following type while providing type hints in some of my code:

import numpy as np
from typeguard import typechecked

@typechecked
def test_numpy(array: np.array):
    print(type(array))

test_numpy([5, 6])

The error in this code is that I use np.array instead of np.ndarray in the type hint. np.array is not a type but a build in function.
Unfortunately Typeguard does not raise any error during the execution because np.array is a built-in function and that is not handled by any of the if statements in the typeguard's check_type function. As a result I had many wrong typing hint that stayed undetected by typeguard.

Describe the solution you'd like
I would like typeguard to raise an error in the scenario shown above, so that I can notice the type hint error.
I managed to get the desired behavior by editing pyguard's __init__.py file to add

    else:
        raise ValueError(f"Typeguard: unsuported type {expected_type}")

at the end of the function check_type here

typeguard/src/typeguard/__init__.py

Line 692 in 56e44c3

This change allowed me to detected many bugs in my type hints.

Is there any drawback in adding this line ? if so could that be controlled by a global variables in typeguard or a parameter provided to the decorator ?

[agronholm]

Is there any drawback in adding this line ? if so could that be controlled by a global variables in typeguard or a parameter provided to the decorator ?

Yes, it will start raising exceptions where there had previously been none. This is particularly troublesome for the import hook which tries to get everything possible type checked. That said, I agree that at least in this particular case, it should probably at least emit a warning.

[martinResearch]

The fact that "will start raising exceptions where there had previously been none" as been actually very useful to me in order to also find other errors in my type annotations.
If there was a flag to activate the execution of the line I suggested to add, that would be great. It would potentially default to false to avoid causing disruption. Even if that emits a warning , one may want the option to deactivate it.
Activating it on a large code base would allow one to spot cases that are missing in the check_type function.

[agronholm]

This could be implemented behind an opt-in configuration item in the v3.0 series.