@api_view decorator doesn't narrow the type of Request.method

[vpavlenko]

@mkurnikov @intgr @sobolevn Thanks for you work! I guess my question is related to #60

I wonder if there's a way for the decorator api_view to propagate the constant http_method_names as Union of Literals attached to Request.method? Consider the following example:

@api_view(["GET", "POST"])
def my_view(request: Request) -> Response:
    reveal_type(request.method)
    if request.method == "GET":
        return Response({})

    elif request.method == "POST":
        return Response({})

mypy yields

views.py:2: error: Missing return statement
views.py:3: note: Revealed type is 'Union[builtins.str, None]'

Or how would you suppress this error?

[sobolevn]

@vpavlenko it would be awesome idea to use tagged unions here. Are you willing to try to implement this?

[kalekseev]

I think it possible to implement only using plugin code, you type your request explicitly with request: Request in arguments, so there is no way for mypy to understand that method should be narrowed to "POST" | "GET" union. You can inherit Request type once per method and use request: PostRequest | GetRequest but this is not good solution because your type may become out of sync with @api_view decorator.

[intgr]

Or how would you suppress this error?

I usually add an else: block that raises an error:

    elif request.method == "POST":
        return Response({})
    else:
        raise AssertionError(f"Unhandled method {request.method}")
        # or:
        assert False, "Unhandled method"

That's enough to suppress the "Missing return statement" error.

[sobolevn]

This can possibly done via plugin, but it is always hard to tell if this is going to work or not. It might be a great addition.

[vpavlenko]

Actually, I'm not sure if there's a way to express that in a current mypy type system. Looks like Literals aren't meant to be parameterized:
https://www.python.org/dev/peps/pep-0586/#illegal-parameters-for-literal-at-type-check-time

So I don't see how we can copy a list of strings and construct a literal to contruct a class type using it.

[Goldziher]

Should be resolved @sobolevn

[sobolevn]

Let's add a test and close it if it works.

[charettes]

For the record I don't think it is resolved as I don't see any type narrowing for api_view in the plugin and I can still reproduce against the lasted version.