How to use _typeshed.wsgi with typing.get_type_hints

[adaamz]

Hello there,
is there a way to get to work combination of _typeshed.wsgi and typing.get_type_hints in runtime?
In flask codebase there is something like

from __future__ import annotations

import typing as t

if t.TYPE_CHECKING:  # pragma: no cover
    from _typeshed.wsgi import WSGIApplication  # noqa: F401
    from werkzeug.datastructures import Headers  # noqa: F401
    from werkzeug.sansio.response import Response  # noqa: F401

# The possible types that are directly convertible or are a Response object.
ResponseValue = t.Union[
    "Response",
    str,
    bytes,
    t.List[t.Any],
    # Only dict is actually accepted, but Mapping allows for TypedDict.
    t.Mapping[str, t.Any],
    t.Iterator[str],
    t.Iterator[bytes],
]

# the possible types for an individual HTTP header
# This should be a Union, but mypy doesn't pass unless it's a TypeVar.
HeaderValue = t.Union[str, t.List[str], t.Tuple[str, ...]]

# the possible types for HTTP headers
HeadersValue = t.Union[
    "Headers",
    t.Mapping[str, HeaderValue],
    t.Sequence[t.Tuple[str, HeaderValue]],
]

# The possible types returned by a route function.
ResponseReturnValue = t.Union[
    ResponseValue,
    t.Tuple[ResponseValue, HeadersValue],
    t.Tuple[ResponseValue, int],
    t.Tuple[ResponseValue, int, HeadersValue],
    "WSGIApplication",
]

https://github.com/pallets/flask/blob/3.0.0/src/flask/typing.py
and in my application I use something like

from flask.typing import ResponseReturnValue

@inject
def my_endpoint() -> ResponseReturnValue:
    return "asdf"

...
def inject(method):
    ...
    arg_types = typing.get_type_hints(method)
    # get args from DI container and call actual function with injected args

which ends with error like

NameError: name 'Response' is not defined

Here is complete playground for my issue https://www.online-python.com/AsZX867MEO

I can probably use my own type for that - that's why I ask here - but not sure how to use typeshed in runtime.
Then I can probably send PR directly to flask with fix for such edge cases (as nobody probably encountered this based on how long this is in flask already).

Thanks for you tips and help in advice.

[Daverball]

@adaamz If you are trying to access the type hint at runtime you currently can't have any type checking only imports. You are importing Response in a if TYPE_CHECKING: block so it's not available at runtime, hence the exception when you try to use get_type_hints. (The other two symbols will cause exceptions too, Response just happens to be the first symbol it tried to lookup which didn't exist at runtime). Since typeshed is only available for type checking there will be no way to fully do this at runtime, without defining your own runtime type aliases.

PEP649 would partially remedy this by allowing partial evaluation of annotations, i.e. the Response would be substituted with a ForwardRef("Response") instead of throwing an exception, but that might still be somewhat useless if you actually wanted to be able to fully verify the type at runtime.

If you don't actually care about verifying the types as much and want to do something less powerful to distinguish between a couple of well defined cases, you can look at method.__annotations__ instead, which should just contain plain strings with your from __future__ import annotations import.

Another way to deal with this would be to use the globalns/localns arguments in get_type_hints to insert some sentinel values for the symbols you are missing, but that wouldn't be a complete solution and would rely on you knowing in advance which symbols won't be available at runtime (or to do something very slow where in a loop you progressively replace symbols with ForwardRef(symbol_name) in the globalns or localns every time you get a NameError(symbol_name)).

[adaamz]

Hello @Daverball,
thank you for your response 🙂
Basically I dont't care about return types at all- they can be whatever or basically missing. All I care about is what is in arguments - based on that I take instance from DI container and pass it to function call.

Annotations might be the solution - tbh because method.annotation returns string we started using get_typehints instead, because we register stuff to DI container by type and not string. Also I think this string annotation contains alias which I cannot resolve easily in my DI library.

[Daverball]

Yeah until PEP649 becomes a thing (Python 3.13 at the earliest, although maybe they'll allow accessing the feature in earlier versions of Python via from __future__ import annotations) there's no (easy) way to resolve type hints partially or only look at parts of the type hints (i.e. ignoring the return annotation). I did start a discussion about this on the Python Discourse: https://discuss.python.org/t/dealing-with-forward-refs-at-runtime/37558

You pretty much have to write your own logic based on __annotations__ right now. You can look at the implementation for typing.get_type_hints for how you might accomplish this: https://github.com/python/cpython/blob/3.12/Lib/typing.py#L2139

[Akuli]

This was apparently closed accidentally with a typo in a merge commit message.