Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mypy issues with non-async resolvers #95

Open
AlexanderWells-diamond opened this issue Aug 9, 2023 · 0 comments
Open

mypy issues with non-async resolvers #95

AlexanderWells-diamond opened this issue Aug 9, 2023 · 0 comments

Comments

@AlexanderWells-diamond
Copy link
Contributor

As found in PR #94, it seems that there are some type errors present:

src/coniql/strawberry_schema.py:145: error: Incompatible types in assignment (expression has type "coniql.types.ChannelValue | None", variable has type "coniql.strawberry_schema.ChannelValue | None")  [assignment]
src/coniql/strawberry_schema.py:147: error: Incompatible types in assignment (expression has type "coniql.types.ChannelTime | None", variable has type "coniql.strawberry_schema.ChannelTime | None")  [assignment]
src/coniql/strawberry_schema.py:149: error: Incompatible types in assignment (expression has type "coniql.types.ChannelStatus | None", variable has type "coniql.strawberry_schema.ChannelStatus | None")  [assignment]

These seemed to have been caused by an update to Strawberry, in version 0.186.0, where parts of the MyPy plugin were removed. For reasons unknown, having the resolvers as async functions seemed to mask the error they found.

I believe these errors are valid - we are indeed returning a types.ChannelValue when we specify it should be a strawberry_schema.ChannelValue. I don't know the exact mechanism that's running that enables this apparent conflict to successfully resolve itself - logically the two are differently structured and so should not be interchangeable.

This may also be a good time to do something about all the near-duplicate names we have - there's one set in strawberry_schema.py that mirror the names of types found in types.py. Conceptually this is to provide a mapping between the Strawberry and the Python representation of objects, but perhaps we should revist this (and/or just scrap the Python versions and do it all in the Strawberry classes, making use of private fields).

AlexanderWells-diamond added a commit that referenced this issue Aug 9, 2023
See issue #95 for when to remove these
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant