pythonpython-typingpylance

Why do Python type hints sometimes worsen IDE recommendations?

I'm going through an exercise of adding type hints through a large codebase, but I'm sometimes seeing that less-than-optimal type hint worsens IDE recommendations:

Before, the IDE is able to figure out that y['result'] is a string:

Enter image description here

After, it does not know:

Enter image description here

I know I could fix this with a more specific type hint:

Enter image description here

But in general, is there a way to know if the type hint being added is less specific that what the LSP was able to infer from the code?

I've looked to add very detailed type hints to avoid this issue (e.g., subclassing TypeDict), but I am keen to avoid the effort if the LSP is able to figure things out itself.

I'm asking if there is a way to warn the user when they are adding a type hint that will worsen the LSP's understanding of the code:

We have warnings when the type hints contradict the code:

Enter image description here

I'm looking for some warning for when the type hint is worse than no type hint at all.

Enter image description here

You can see here that the LSP was easily able to infer a pretty detailed return type.

Enter image description here

Which would have been lost if the user added a "bad" type hint.

Enter image description here

But I take the overall feedback. Maybe this is an ask to the Pylance project more than a Stack Overflow question.

Solution

  • No, it is not currently possible for the type checker to tell you if your hint will worsen the LSP's understanding. Both in your example of Visual Studio Code (which uses Pyright underneath), and mypy.

    While theoretically possible for type checkers to implement, needing this feature is a red flag. This is because your LSP should provide suggestions based on the interface of the function (return type), not implementation (function body). Otherwise, your LSP would be providing suggestions that would break when the implementation of a function you consume changes, even if its behavior remained the same!

    You say:

    I'm going through an exercise of adding type hints through a large codebase

    If you want to ensure your LSP retains optimal understanding of the code, you should only start adding type hints to functions that are used by other modules / packages in your code. This will get the major benefit of type hinting (establishing an interface to other team members / consumers of your service).

    As for private functions, you do not need to type hint those yet. This allows you to treat their implementation as the interface, which is not a bad idea for internal code. The downside of type hinting you are experiencing (the chance of removing information from the interface accidentally) is then deferred.