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).
As found in PR #94, it seems that there are some type errors present:
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
asyncfunctions seemed to mask the error they found.I believe these errors are valid - we are indeed returning a
types.ChannelValuewhen we specify it should be astrawberry_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.pythat mirror the names of types found intypes.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).