Python Language Summit 2020 - Python Typing
Written by Mike James   
Saturday, 02 May 2020

Python Summit has gone virtual for obvious reasons. There are lots of interesting talks, but the one that piqued my interest was on the gradual addition of gradual typing to Python. I was going to call the news "Python typing considered harmful", but then I thought better of it.


I really didn't want to bring the hounds of html down on myself, but let Guido van Rossum enlighten you:

"There are a lot of PEPs about typing!" said Guido van Rossum at the Language Summit. Since 2014 there have been ten PEPs approved for Python's type-checking features. Two of them have been approved already this year: the relatively "esoteric" PEP 613: Explicit Type Aliases, and another that will have widespread impact, PEP 585: Type Hinting Generics In Standard Collections, written by Łukasz Langa and mainly implemented by van Rossum."

Notice the use of the term "esoteric" - it sounds as if Guido isn't a true believer at the bottom of it.

The nice thing about Python is that you can avoid typing altogether, but if you do feel guilty about it you can use optional typing. This seems easy at first and even rewarding.

What could be wrong with specifying the signature of a function? But then the rot sets in. Things get complicated. You have to invent how to type complicated things like functions as a whole or  data structures. You have invent generics and that's not easy and then there is the whole issue of covariance and contravariance. All tough to understand and hard to get right.

it quickly goes from a fun game with ints to a nightmare with:

class MyClass(Generic[T]):
  def __init__(self,value:T)->
None: self.myAttribute:T=value

and worse.

Python type annotations don't actually do anything unless you run a type checker, mypy for example, so I suppose they are not that restrictive. But that just makes using them even less useful.

Python seems to be accumulating type annotation like a rock gathers moss.

"Yury Selivanov noted that typing.Optional[t] could be replaced with t | None, and asked whether it could be shortened further as t?. "Every year," replied Van Rossum, "there's another feature that people want to use the question mark for." In his opinion, t | None is convenient enough, and another syntax would be redundant. "

Good job Guido is still there to limit its spread. When asked about progress on typing, he said that he had moved on to retirement and that the Python static mailing list needed more people to join.

I write fairly big Python programs and I can honestly say that I have never had an error that strong typing would have helped me find or stopped me from making. I know I'm expressing a minority view, but I think the Python type annotation experience is evidence that the minority might have a point.


  • Mike James has recently completed work on Programmer's Python: Objects & Attributes, the first volume in his Programmer's Python: Something Completely Different series. In preparing this book he has developed a new passion for Python 3.

More Information

The path forward for typing - Python Language Summit 2020

This is an account of the talk written by  A. Jesse Jiryu Davis from which all the quotes come from. Do read the account  - it has much more to say than covered in this news item.

Related Articles

Programmer's Python - Type Annotation

Python Development Trends

What Makes Python Special?

Python 3 For Science - A Survey

Jupyter Receives ACM Award


To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.



JetBrains Releases Aqua Test Automation IDE

JetBrains has announced the public release of Aqua, its IDE designed for test automation. The full release follows a preview in 2022.

Women Who Code Closing For Lack of Funding

Women Who Code the US-based non-profit organization that since its foundation in 2011 has advocated for women and diversity in technology, has announced its imminent closure due to critical funding cu [ ... ]

More News


raspberry pi books



or email your comment to:






Thanks to this PEP, types which had been defined like List[int] can now be spelled list[int], with a lowercase "L". As Van Rossum told the Python Language Summit, "We want to avoid a world where users have to remember, 'Here I have to use a capital-L List and here I use a lowercase-L list.'"

Read more 2020 Python Language Summit coverage.

A "generic" is a type that can be parameterized with other types. Generics are usually container types. Since Python 3.5, the typing module has provided "type aliases" like List, which can be parametrized with the type of values it contains, like List[str] in this type-annotated function definition:

from typing import List
def greet_all(names: List[str]) -> None:
    for name in names:
        print("Hello", name)

Van Rossum showed the Summit the following code, demonstrating that the ordinary built-in list and dict classes can now be used as generics for type annotations:

>>> p = list[int]
>>> p
>>> p.__origin__
<class 'list'>
>>> p.__args__
(<class 'int'>,)
>>> p((1, 2, 3))
[1, 2, 3]
>>> from typing import TypeVar; T = TypeVar("T")
>>> dict[str, T][int]
Dict[str, int]

The syntax list[int] is enabled by implementing __class_getitem__ on list. The built-in containers such as tuple, dict, list and set are supported, along with some standard library containers and abstract base classes, including collections.deque,, queue.Queue, and re.Pattern. The effect for everyday coders is mainly a matter of spelling, yet as Van Rossum said, "It's probably going to affect everyone's code, or everyone will encounter code like this." Fewer users will have to import type aliases such as List from the typing module; it will be required only for advanced annotations. Van Rossum asked the Summit, "How much of this do we want to make built in?"

Python's approach to type-checking is to add type annotations in the source code, but to check types neither during compilation nor at runtime. Instead, programmers use a separate type-checker (such as mypy or PyCharm). The new PEP 585 type annotations are the same: they do no checking at all, so "nonsense" annotations like list[str, str] are permitted. It is the type checker's job to reject them.

Annotations are not completely free at runtime, however: by default an annotation like List[int] is evaluated to create a type object when it is encountered, usually at module-load time. This can noticeably hurt startup times for big type-annotated programs. PEP 563 Postponed Evaluation of Annotations was introduced in Python 3.7 to solve this problem: type annotations are saved as strings, and evaluated only when a type checker such as mypy requests it. This optimization is currently guarded behind from __future__ import annotations. Van Rossum asked whether postponed evaluation should become the default in Python 3.9, which will be released imminently, or 3.10.

Also in Python 3.10 will be PEP 604, which permits the current Union[t1, t2] annotation to be spelled as t1 | t2, using the vertical bar to express a union of types. The PEP's scope might expand to add syntax that even programs without type annotations would enjoy. For example, isinstance(x, (t1, t2)) could be written isinstance(x, t1 | t2), and an exception handler could be written like except t1 | t2.

Yury Selivanov noted that typing.Optional[t] could be replaced with t | None, and asked whether it could be shortened further as t?. "Every year," replied Van Rossum, "there's another feature that people want to use the question mark for." In his opinion, t | None is convenient enough, and another syntax would be redundant. (Although the new PEG parser would make it easy to implement.)

Stéphane Wirtel asked if Python would ever have exception annotations. "Ouch!" said Van Rossum. The consensus is that Java's checked exceptions were a bad idea, and would probably be bad in Python too. "I don't think I have the stomach for that."

The standard library and most PyPI packages have no type annotations. Type-hinted "package stubs" for this code are hosted in the typeshed repository, but storing all those stubs in a monolithic distribution doesn't scale, and the problem will grow worse. In a GitHub issue thread, Jukka Lehtosalo predicted that in two years, stubs for third-party packages will outnumber those for the standard library, and in five years, typeshed will include more than 1000 third-party packages. As Van Rossum told the Language Summit, Lehtosalo's proposal will split typeshed into separate distributions so users can easily download just the stubs they need, consistent with PEP 561.

Brett Cannon asked whether the standard library's annotations should be shipped with Python, either as stub files or in the code itself. Van Rossum said new stdlib code should be written with annotations inline, but old code includes optimizations and strange legacy behaviors that defy static typing. Currently mypy does not analyze standard library code because "it assumes that the standard library is full of untyped shit," it looks in typeshed instead. If indigenous type annotations grew in the standard library, the core team would have to coordinate with type checker authors to manage the change.

Van Rossum offered an update on mypy. He admitted he hadn't been active on mypy recently, and "my former colleagues at Dropbox have not been able to make as much progress as we did in the past." Support for NumPy is stalled. The same goes for decorators, although once PEP 612 is approved it will provide a prerequisite for decorator support in mypy. Raymond Hettinger asked if mypy development needs funding. Michael Sullivan, a mypy contributor from Dropbox, replied that Dropbox considers mypy mostly complete, and has moved on to projects like their Python 3 migration. Van Rossum said funding could help. Personally he has "moved on to retirement." The Python static typing mailing list is quieter than Van Rossum would like, interested people should join.

There's better news about mypyc, an experimental project to translate type-annotated Python into C. The translator's main use for now is converting mypy to C for speed. There is work in progress to allow a mix of Python and Python-translated-to-C in the same program, and to write documentation. The mypyc project expects a Google Summer of Code student this summer.
Posted by A. Jesse Jiryu Davis at 4/30/2020 10:34:00 PM
Newer Post Older Post Home
The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

    Python Software Foundation
    Grants Program
    Meeting Minutes

Blog Archive

    ▼  2020 (18)
        ►  May (1)
        ▼  April (11)
            Lightning Talks Part 1 - Python Language Summit 20...
            The 2020 Python Language Summit
            The path forward for typing - Python Language Summ...
            CPython Documentation: The Next 5 Years - Python L...
            HPy: a future-proof way of extending Python? - Pyt...
            A formal specification for the (C)Python virtual m...
            Replacing CPython’s parser - Python Language Summi...
            Building a Python community in Colombia: John Roa,...
            Thank you to donors & sponsors
            Python Software Foundation Fellow Members for Q1 2...
            Announcing a new Sponsorship Program for Python Pa...
        ►  March (4)
        ►  January (2)

    ►  2019 (45)

    ►  2018 (31)

    ►  2017 (32)

    ►  2016 (27)

    ►  2015 (67)

    ►  2014 (14)

    ►  2013 (18)

    ►  2012 (21)

    ►  2011 (55)

    ►  2010 (35)

    ►  2009 (21)

    ►  2008 (23)

    ►  2007 (26)

    ►  2006 (39)


Last Updated ( Saturday, 02 May 2020 )