Due date's type is partially unknown in pyright strict mode

[AlexZasorin]

Bug description

I'm running into an issue with the ApiDue type where pyright (and basedpyright) report it as being partially unknown in strict mode.

error: Type of "date" is partially unknown
Type of "date" is "DatePattern[Unknown] | DateTimePattern[Unknown] | UTCDateTimePattern[Unknown]" [reportUnknownMemberType]

It's entirely possible that I'm doing something wrong here, or this is an issue with pyright/basedpyright, so apologies if this is better as a question rather than a bug report.

Expected behaviour

I expected that the usage of the ApiDue type (e.g. task.due.date) does not give a partially unknown error in pyright strict mode.

Is reproducible

Yes

To reproduce

    todoist_api = TodoistAPIAsync('token')
    task_generator = await todoist_api.filter_tasks(query=filter)
    async for task_list in task_generator:
        for task in task_list:
            if task.due:
                print(task.due.date)

Steps taken to try to reproduce

N/A

Screenshots

Version information:

• Package version: 3.01
• Python version: 3.13

Additional information

N/A

[goncalossilva]

Hey @AlexZasorin, thanks for reporting! For now, please consider using # type:ignore[call-arg].

I'm not exactly sure why this happens, though I suspect there is an issue with dataclass-wizard, with the way we're using it, or a Pyright bug. If you have more insight, do share! In the meantime, I've reported it here.

[AlexZasorin]

Thanks @goncalossilva! Your response is much appreciated. I'll use that type ignore comment for now.

Just to test I tried modifying ApiDue to be

ApiDue = DatePattern["%F"]

but I got basically the same error. I also get a similar error trying to access any property typed as ApiDate (aka UTCDateTimePattern["%FT%T.%fZ"].

[festeh]

I don't think that's a pyright issue, since it does static code analysis and is not able to say which type would be actually used without evaluating Python code. The actual type of ApiDue is datetime | date, but I guess datetime-wizard won't deserialize to it correctly without specifying patterns?

[goncalossilva]

It does require parameters to know what format to deserialize from at least (which is how we use it).

My current understanding of this issue is that it sits upstream. If anyone has a suggestion of a change I can make here to mitigate the issue temporarily, I'm all ears. If not, for now, # type:ignore will have to do.