[New-bugs-announce] [issue34700] typing.get_type_hints doesn't know about typeshed

[Ben Darnell]

New submission from Ben Darnell <ben.darnell at gmail.com>:

Currently, most type annotations for the standard library are provided in typeshed rather than in the library itself. Not all consumers of type annotations are aware of typeshed, and this can cause problems. Specifically, Sphinx 1.8 accesses type hints via `typing.get_type_hints()`, which fails for some hints which are (implicitly) relying on typeshed. This currently manifests as failures to build Tornado's docs with Sphinx 1.8 (Tornado is using inline type annotations).

Concretely, the issue involves the `concurrent.futures.Future` class. In typeshed, this class is a `Generic[T]`, but in the standard library it's just a normal class. Consider a function that returns a parameterized Future type:

    from concurrent.futures import Future

    def do_something_background() -> 'Future[int]':
        return executor.submit(do_something)

Note that the type annotation is already a string. We can't use `Future[int]` directly because at runtime, the real Future type is not subscriptable. The string defers resolution of the subscript until something tries to access the annotation *as a type hint*. When mypy does this, it uses the typeshed definition of Future, so everything passes. But when Sphinx calls `typing.get_type_hints()` on this function, it fails:

```
>>> typing.get_type_hints(do_something_background)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 1543, in get_type_hints
    value = _eval_type(value, globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 350, in _eval_type
    return t._eval_type(globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 245, in _eval_type
    eval(self.__forward_code__, globalns, localns),
  File "<string>", line 1, in <module>
TypeError: 'type' object is not subscriptable
```


What can be done about this? I see a few approaches:

1. Require that any use of type hints consults typeshed. This would entail either making typing.get_type_hints aware of typeshed or deprecating and removing it.

2. Disallow references to typeshed from inline type annotations; types that require typeshed must only appear in `.pyi` stubs, which will only be interpreted by tools like mypy that know about typeshed. (is this true, or are there tools that know about pyi files but not typeshed?)

3. Annotate types in the standard library as generic. So far, this problem has always taken the form of "type is not subscriptable", and it could be resolved by making all generic types in the stdlib subclasses of `typing.Generic[T]`. This would bring enough typing detail into the stdlib to allow the annotations to be parsed without typeshed. This would also avoid the need for the awkward quotes in the example above.

----------
messages: 325455
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: typing.get_type_hints doesn't know about typeshed
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________