A Python static typing update

One of the larger features added to Python over the last few releases is support for static typing in the language. Static type-checking and tools to support it show up frequently as topics at the Python Language Summit (PLS) and this year was no exception. Mypy developers Jukka Lehtosalo and Ivan Levkivskyi gave an update on static typing at PLS 2018.

Lehtosalo started things off by talking about stub files, which contain type information for libraries and other modules. If you are going to type-check code that uses outside modules, from the standard library or a third-party library, the tool needs to understand the types used in the public interfaces of the library. The type-checking that can be done is limited if there are no stubs for the libraries used.

Right now, static typing is only partially useful for large projects because they tend to use a lot of packages from the Python Package Index (PyPI), which has limited stub coverage. There are only 35 stubs for third-party modules in the typeshed library, which is Python's stub repository. By comparison, there are 200 stubs for standard library modules even though PyPI is much larger than the standard library.

He suggested that perhaps a centralized library for stubs is not the right development model. Some projects have stubs that live outside of typeshed, such as Django and SQLAlchemy. But that makes those stubs a hassle to use. PEP 561 ("Distributing and Packaging Type Information") will provide a way to pip install stubs from packages that advertise that they have them. The current draft version of PEP 561 is supported by mypy.

There are still some areas where Python's type hints (as defined in PEP 484) are not sufficient, especially where the types are derived from runtime parameters. For example, Django models have a create() method that is dependent on the definition of the model; PEP 484 has no way to express that relationship. Lehtosalo mentioned other examples, including NumPy arrays where the array dimensions are not compatible for a particular operation; once again, type hints cannot help there.

At that point, Levkivskyi took over to describe the changes coming in Python 3.7 for type hints. PEP 560 ("Core support for typing module and generic types") has been accepted and will improve the performance of the typing module. Importing the typing module is seven times faster now, he said.

PEP 563 ("Postponed Evaluation of Annotations") will solve some of the pain points that people have experienced using the typing module, he said. It will mean that forward references to types will no longer need to be escaped as string literals. It will also stop automatically processing type annotations when importing modules, so that only those doing type-checking will pay the price at import time. Importing annotations from the __future__ module will enable the functionality for programs that want it (and are prepared to deal with the break in backward compatibility).

A work that is currently in progress is PEP 544 ("Protocols: Structural subtyping (static duck typing)"). It will allow type-checkers to infer support for some Python protocols (such as Iterable) for a class rather than require that the class be explicitly marked to support the protocol. The PEP is close to acceptance, Levkivskyi said, and mypy fully supports it.

Another addition is the TypedDict type, which allows a dictionary with fixed keys and known value types to be declared. If a Movie type is a dictionary with two keys (name and year), it could be declared this way:

    Movie = TypedDict('Movie', {'name': str, 'year': int})

That would allow type-checkers to infer types, complain for incorrect keys, and give errors when the wrong types are assigned. TypedDict needs a short PEP that has not been written yet; mypy does not fully support it yet, either.

Index entries for this article
Conference	Python Language Summit/2018
Python	Static typing

---

to post comments