Making PyCharm type-checker more robust

This seems to be too broad for an individual issue, but I think PyCharm type-checker can be made a lot more useful by taking a large project and fixing all the spurious warnings.

An example is taking, and running type checker. There are a few hundred warnings. Some of them are due to incorrect .pyi stubs while others seem to by PyCharm problems.

Incorrect pyi stubs should be handled by allowing user to specify exclusions to silence TypeChecker until those problems are fixed upstream.

Others seem to be problems on PyCharm side. Some examples

- "len(self._modules)" triggers "Expected type 'Sized', got 'OrderedModuleDict' insted"

It seems unreasonable to expect user to declare their class to be child of "Sized" whenever they implement __len__ method

- expected type "xyz", got None instead.

PyCharm seems to infer type automatically to by xyz instead of "Optional[xyz]"

- type 'str' doesn't have the expected attribute 'decode'

But str does have this attribute...

- expected type 'int', got 'float' instead

This one is probably because method has initial value like "a=5". However, floats are compatible with ints, so this should not be a warning. 

- expected type 'int' got 'ndarray' instead

ndarray is meant to be interchangeable Python numeric types. Basically 1+5 or np.array(1)+5 are equivalent.

1 comment
Comment actions Permalink

Hi, we have a few issues with type hinting and torch: - a third party issue

Other general issues might be already known. If you don't find them here ( , you can submit new tickets (one ticket per issue), providing the code snippet and steps to reproduce, so we could process it further.


Please sign in to leave a comment.