Type Hinting in IntelliJ IDEA
IntelliJ IDEA provides various means to assist inspecting and checking the types of the objects in your script. This smart assistance is known as type hinting.
Support for PEP 484 type hints
IntelliJ IDEA supports type hinting in function annotations and type comments using the
typing module defined by PEP 484.
NewTypehelper function in PEP 484 facilitates creating simple classes. Its support can be enabled in IntelliJ IDEA by adding the corresponding import. Below is the example that solves a task opposite to one exampled in PEP 484. It builds a user Id by a user name.
from typing import NewType UserName = NewType('UserName', str) def id_by_name (user_name: UserName) -> int: pass UserName(33) # Integer is not allowed - correct warning id_by_name('John') # String is also not allowed - correct warning id_by_name(UserName('John')) # UserName is ok name = UserName('John') + 'Smith' # UserName object inherits all parent type methods
Adding type hints
Although IntelliJ IDEA supports all methods for adding types supported in PEP 484, using type hints through intention actions is the most convenient way. Depending on the interpreter you use, the type is added as an annotation (Python 3) or as a comment (Python 2).
To add a type hint, follow these steps:
- Select a code element.
- Press Alt+Enter.
- Select Add type hint for ....
- Press Enter to complete the action or edit the type if appropriate.
|Example||Intention Action||Resulting Code|
Specifying types by using comments
# type: comment to specify the types of local variables and attributes:
IntelliJ IDEA supports Python stub files with the
.pyi extension. These files allow you to specify the type hints using Python 3 syntax for both Python 2 and 3.
The stub files are, but you must specify the extension
IntelliJ IDEA shows an asterisk in the left gutter for those Python files that have stubs:
Clicking the asterisk results in jumping to the corresponding file with the
Type hints validation
Any time you're applying type hints, IntelliJ IDEA checks if the type is used correctly. If there is a usage error, the corresponding warning is shown and the recommended action is suggested. Below are the validation examples.
|Validation error||Suggested action|
|Duplication of type declaration.||Remove either of the type declarations.|
|Number of arguments in the type declaration differs from the number of function arguments.||Adjust the number of the arguments.|
|Missing brackets.||Add the required brackets where appropriate.|
Type comments with unpacking do not match the corresponding targets.
Check the target format and modify the type comment accordingly.
|Incorrect syntax of ||Use the suggested format and add the required brackets to wrap |
Enabling postponed evaluation of annotations
IntelliJ IDEA supports changes introduced in PEP-563. With these changes, function and variable annotations are no longer evaluated at function definition time. Instead, a new
__future__ import enables their postponed evaluation. Consider the following sample code:
class Foo: def foo(self) -> 'Foo': ... class Bar: def bar(self, param: 'Bar'): ...
__future__import applied, you can benefit from forward references and avoid using string literals for class definitions:
from __future__ import annotations class Foo: def foo(self) -> Foo: ... class Bar: def bar(self, param: Bar): ...
Legacy type syntax for docstrings
IntelliJ IDEA supports legacy approach to specifying types in Python using docstrings. So doing, the supported formats are:
To choose the desired docstring format, use the Python Integrated Tools page of the Settings/Preferences dialog.
Type syntax in Python docstrings is not defined by any standard. Thus, IntelliJ IDEA suggests the following notation:
|Class Foo visible in the current scope|
|Class Bar from x.y module|
|Foo or Bar|
|Tuple of Foo and Bar|
|List of Foo elements|
|Dict from Foo to Bar|
|Generic type (T-Z are reserved for generics)|
|Generic type with upper bound Foo|
|Foo parameterized with T|
|Function of Foo and Bar that returns Baz|
|List of dicts from str to datetime (nested arguments)|
Specifying types of local variables
Consider adding information about the expected type of a local variable using
It is also possible to use
isinstance to define the expected local variable type:
Specifying types of fields
You can use type hinting to specify the expected type of fields:
Alternatively, you can specify types of fields in the docstring of a class:
Specifying return types
@rtype to specify the expected return type:
:rtype: collections.Iterable[int] # return type: 'items' is of type
collections.Iterable, 'a' is of type
int, see the following code:
def my_iter(): for i in range(10): yield i items = my_iter() for a in items: print a
- :rtype: list[int] for my_iter # return type: 'a' is of type
int, see the following code:
def my_iter(): for i in range(10): yield i for a in my_iter(): print a
Specifying parameter types
Consider adding information about the expected parameter type. This information is specified using
@type docstrings, for example,
:param "type_name" "param_name": "param_description".
For comment-based type hints, IntelliJ IDEA suggests an intention action that allows you to convert comment-based type hint to a variable annotation. This intention has the name Convert to variable annotation, and works as follows:
| || |
Typeshed is a set of files with type annotations for the standard Java library and various packages. Typeshed stubs provide definitions for Java classes, functions, and modules defined with type hints. IntelliJ IDEA uses this information for better code completion, inspections, and other code insight features.
IntelliJ IDEA is switching to Typeshed, the common repository for Java stubs. The Typeshed stubs bundled with IntelliJ IDEA are shown in the project view under the node External Libraries | <Python interpreter> | Typeshed Stubs. Note that IntelliJ IDEA currently uses only a few of the bundled stubs (i.e.
typing.pyi, and several others).
To override the bundled Typeshed repository with your own version, follow these steps:
- Copy some or all the stubs into a directory in your project.
- Mark a directory as a source root by choosing Mark Directory as | Sources Root from the context menu of the directory.
The Python skeletons repository https://github.com/JetBrains/python-skeletons is now deprecated.