How to deal with PyCharm's "Expected type X, got Y instead"

Question

When using PyCharm, Pycharm's code style inspection gives me the warning Expected type 'Union[ndarray, Iterable]', got 'float' instead in the editor if I write np.array(0.0). When I write np.array([0.0]) I get no warning.

When coding

from scipy.special import expit
expit(0.0)

I get Expected type 'ndarray', got 'float' instead, while

expit(np.array([0.0]))

solves that.

What I think Pycharm's code style inspection wants to tell me is there's a possibility of a type error, but I am not sure how I should react to that in the sense of good programming. Is PyCharm right to scold me and should I use the long versions or should I keep my short versions for readability and speed of coding?

If I should not change my code to the long versions - can I get rid of the Pycharm's code style inspection warning, or is that a bad idea, because they may be correct in other cases, and I am not able to tune the warnings that specifically?

Answer 1

PyCharm determines from the type-hints of the source code that the arguments you pass are incorrect.

---

How to disable

Your question simplifies to one of figuring out how to disable this type checking. However, please be warned,

Switching off the inspection completely is not a good solution. Most of the time PyCharm gets it right and this provides useful feedback. If it's getting it wrong, it's best to raise a ticket with them to see if it can be fixed.

You can do that like this:

1. Go to Settings/Preferences

2. On the sidebar, click Inspections

3. Expand the Python tab

4. Scroll down to Type Checker and uncheck it

PyCharm should now stop issuing warnings about incorrect function arguments.

Answer 2

Look at the specifications of the expit function. Nothing there says it's permissible to provide a scalar argument - it calls for a numpy.ndarray. PyCharm is smart enough to tell you that any iterable (and hence a list) is acceptable, but this message isn't a warning - it's telling you your code as written does not meet the function's specifications. As @JonClements points out in a comment, numpy's scalar broadcasting feature will allow this code to run, but PyCharm isn't smart enough to deduce this.

NOTE: the answer from @cs95 explains how to disable the type checking, and it may be more appropriate as the accepted answer.