Skip to content

Issue with ClassVar #276

Closed
Closed

Description

@Goldziher

Hi there,

So I encountered the following issue. I have a base class with some ClassVars:

class MsgSpecSignatureModel(Struct):
    dependency_name_set: ClassVar[Set[str]]
    field_plugin_mappings: ClassVar[Dict[str, PluginMapping]]
    return_annotation: ClassVar[Any]
    signature_fields: Dict[str, SignatureField]

    # ...

I get the following error:

self = <msgspec.inspect._Translator object at 0x115541ad0>

    def run(self):
        # First construct a decoder to validate the types are valid
        if self.protocol in (None, "msgpack"):
            from ._core import MsgpackDecoder as Decoder
        elif self.protocol == "json":
            from ._core import JSONDecoder as Decoder
        else:
            raise ValueError("protocol must be one of None, 'msgpack', 'json'")
    
>       Decoder(Tuple[self.types])
E       TypeError: Type 'typing.ClassVar[typing.Set[str]]' is not supported

Activity

  1. jcrist commented on Jan 28, 2023

    @jcrist
    Member

    Thanks for opening this issue!

    Due to type annotation limitations, ClassVar is surprisingly non-trivial to support in the presence of PEP 563 (especially doing so efficiently).

    Previously I had punted on this and not supported it - to use ClassVars on structs with previous releases of msgspec you can use a # type: comment instead of a true type annotation:

    class MsgSpecSignatureModel(Struct):
        dependency_name_set = set()  # type: ClassVar[Set[str]]
        field_plugin_mappings = {}  # type: ClassVar[Dict[str, PluginMapping]]
        return_annotation = None  # type: ClassVar[Any]

    This worked, but wasn't the most developer friendly.

    After some thought (and reading CPython source code) I've successfully found a way to support ClassVar on struct types for common cases. The fix is in #281.

    This won't successfully detect all ClassVar uses when PEP 563 is enabled, but the cases that won't be detected are uncommon (and the limitations are documented). See the docs update in the PR for the limitations.

    I hope to cut a release early this week, so you should have access to this fix in the near-ish future.


    I get the following error:

    In the future, please include the full traceback when reporting error messages, and at least the python line that caused the error. I was able to debug your issue because I was aware of the limitation you ran into, but if I wasn't I wouldn't be able to reproduce the error with only the code you posted.

    Stackoverflow has a pretty good guide on what makes for a good bug report. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions