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.

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).

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().

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.