[issue34700] typing.get_type_hints doesn't know about typeshed

[Guido van Rossum]

Guido van Rossum  added the comment:

Yeah, the Sphinx use case is somewhat different from the originally envisioned 
use case for get_type_hints().  Possibly Sphinx could just directly inspect 
__annotations__ rather than calling get_type_hints()?  I'm not sure if there's 
any situation where it would need the things that get_type_hints() is supposed 
to take care of.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34700] typing.get_type_hints doesn't know about typeshed

[Jakub Stasiak]

Change by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34700] typing.get_type_hints doesn't know about typeshed

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
assignee:  -> levkivskyi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34700] typing.get_type_hints doesn't know about typeshed

[Ben Darnell]

Ben Darnell  added the comment:

Yeah, I think that would work at least for the sphinx use case. It seems like a 
strange partially-degraded mode and anything that needs structured access to 
the annotation would still need typeshed, but just getting the string would 
probably be enough for a lot of applications. In fact, sphinx *only* wants the 
string (AFAICT), so a separate method like get_type_hints_as_string() which 
stringifies everything even if it can be resolved might be a better route than 
an option to get_type_hints().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34700] typing.get_type_hints doesn't know about typeshed

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

I think there is also a fourth option: add a flag to `get_type_hints()` that 
will guard evaluation of forward references, as proposed in 
https://github.com/python/typing/issues/508. If the evaluation of a "forward 
reference" raises an error, then we keep it unevaluated (i.e. a string).

--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34700] typing.get_type_hints doesn't know about typeshed

[Ben Darnell]

New submission from Ben Darnell :

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 "", line 1, in 
  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 "", line 1, in 
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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com