mypy calls error: Class cannot subclass 'ObjectType' (has type 'Any') on graphene

Question

I am building graphQL schema using graphene and static type checking with mypy. The code for schema starts like below:

from typing import Dict, List, NamedTuple, Union    
import graphene


class PossibleAnswer(graphene.ObjectType):
    """Object representing single possible answer, a pair of key and text."""

    paId = graphene.String(
        description="Answer id, automatically generated sequence number.")
    text = graphene.String(description="Answer text, in requested language")

When I run mypy check with --ignore-missing-imports --strict options I get error:

error: Class cannot subclass 'ObjectType' (has type 'Any')

I found a workaround put a # type: ignore to silence the error, but I need to solve this, not mute. Changing mypy options is not an option.

How can I tell mypy that this is graphene type, not Any type of the object I am creating?

Answer 1

The cleanest and most principled solution to this problem is to create stubs containing type hints for the graphene library. You can then either point mypy at those stubs locally or look into contributing them back into the library itself (e.g. turn graphene into a PEP 561 compatible package) or contribute the stubs to typeshed.

As a note, those stubs don't necessarily need to be complete. You could probably silence a majority of mypy's errors by defining some minimal stubs that contain just the core classes within that library and leaving most other things dynamically typed. (You could then flesh out your stubs over time, instead of having to put in the investment to write them all once.)

Anyways, the core rule to remember here is that if some package does not use type hints, mypy will not try and infer anything about it and will assume everything you import from it is of type Any. If you aren't willing to add type hints to help mypy understand the library, unfortunately the only strategies left are to use workarounds like tacking on # type: ignore.

(That said, I don't think adding on # type: ignore comments is necessarily the worst thing in the world here. Using the --ignore-missing-imports flag is effectively equivalent to adding a # type: ignore to every single failed import in your codebase. In that light, muting a few more errors wouldn't really hurt.)