New submission from Ben Darnell <ben.darn...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue34700>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
