Silent type failure

[tbenst]

I have a function as follows:

import numpy as np

file = str

def process_file(my_path: file) -> (List[np.ndarray]):
    return(['bad return'])

It appears that 'np.ndarray' is being interpreted as 'Any'. Why is that? The type is failing silently.

Thanks,
Tyler

[JukkaL]

When I try to type check the file, mypy says No module named 'numpy', because there is no stub for numpy. When this happens, mypy treats any type from the module as Any, as it doesn't know which types are defined or not in the module. Are you seeing this same error?

However, I'm not convinced that this is the best possible behavior when we can't find a stub. Maybe mypy should complain that np.ndarray is not a valid type.

(Of course, the best behavior would be to provide a stub for numpy, but some features in numpy make it difficult to provide a good stub.)

[tbenst]

Yes, I do see the No module named 'numpy' error. Perhaps it would be helpful to explicitly say warning: np.ndarray interpreted as Any. for each line?

Even better would be to support arbitrary class object regardless of stub status:

def check_object_type(to_check: Any, class_hint: Any) -> bool:
    """Return true if to_check matches class_hint.

    Tests:
    >>> import numpy as np
    >>> check_object_type(np.array([1,2,3]),np.ndarray)
    True
    >>> check_object_type([1,2,3],np.ndarray)
    False
    """
    if type(to_check) is class_hint:
        return(True)
    else:
        return(False)

As long as the user always labels function returns for modules without stubs, that would enable this to be type checked properly:

    def process_file(my_path: file) -> (List[np.ndarray]):
        my_list = []
        x = np.loadtxt(my_path) # type: np.ndarray
        my_list.append(x)
        # return(['bad return'])
        return(my_list)

[JukkaL]

Hmm... that would have the problem that mypy couldn't know about inheritance relationships and some other things, and it could complain about valid things. Giving a warning or error when trying to use a type defined in an unknown module is probably the least surprising thing to do.

[tbenst]

Makes sense. Perhaps then an approach is to follow the example by
Racket/Lisp and provide a mechanism for a user to write type
definitions/checkers themselves? This has the advantage of supporting
complexity beyond the current scope of mypy, e.g. polymorphism.
On Wed, Nov 18, 2015 at 7:55 PM Jukka Lehtosalo [email protected]
wrote:

Hmm... that would have the problem that mypy couldn't know about
inheritance relationships and some other things, and it could complain
about valid things. Giving a warning or error when trying to use a type
defined in an unknown module is probably the least surprising thing to do.

—
Reply to this email directly or view it on GitHub
#978 (comment).

[JukkaL]

Mypy will likely get a some sort of type checker plugin mechanism in the future. It's probably going to be needed for things like SQLAlchemy anyway.

[tbenst]

Great to hear! I think a plugin mechanism will be crucial for adoption, especially where stubs are difficult/not available.

[gvanrossum]

Let's close this issue; the plugin feature will be discussed in #1240.