Typing errors with latest pyright version and strict checks.

[fau-st]

Hello,
I'm trying to use this library in a project where pyright is setup with typeCheckingMode="strict" and I'm encountering a few typing errors.

Environment data

• githubkit[auth-app]==0.11.7
• Python 3.12
• pyright 1.1.371

Code Snippet

from __future__ import annotations

from typing import TYPE_CHECKING


if TYPE_CHECKING:
    from githubkit import AppInstallationAuthStrategy, GitHub
    from githubkit.versions.latest.models import (
        PullRequest,
        WebhookPullRequestSynchronize,
    )


def check_pr(*, github: GitHub[AppInstallationAuthStrategy], pull_request: PullRequest):
    github.rest.checks.create(  # POSITION 1
        owner=pull_request.base.repo.owner.login,
        repo=pull_request.base.repo.name,
        name='some-check',
        head_sha=pull_request.head.sha,
        status='in_progress',
    )


def handle_synchronize(event: WebhookPullRequestSynchronize):
    if event.installation:  # POSITION 2
        pass

Behavior

When running pyright with default parameters and typeCheckingMode="strict" I encounter these errors:

• At POSITION 1:

error: Type of "create" is partially unknown
    Type of "create" is "Overload[(owner: str, repo: str, *, headers: Dict[str, str] | None = None, data: ReposOwnerRepoCheckRunsPostBodyOneof0Type | ReposOwnerRepoCheckRunsPostBodyOneof1Type) -> Response[CheckRun], (owner: str, repo: str, *, data: Unknown = UNSET, headers: Dict[str, str] | None = None, name: str, head_sha: str, details_url: Unknown | str | None = UNSET, external_id: Unknown | str | None = UNSET, status: Literal['completed'], started_at: Unknown | datetime | None = UNSET, conclusion: Literal['action_required', 'cancelled', 'failure', 'neutral', 'success', 'skipped', 'stale', 'timed_out'], completed_at: Unknown | datetime | None = UNSET, output: Unknown | ReposOwnerRepoCheckRunsPostBodyPropOutputType | None = UNSET, actions: Unknown | List[ReposOwnerRepoCheckRunsPostBodyPropActionsItemsType] | None = UNSET) -> Response[CheckRun], (owner: str, repo: str, *, data: Unknown = UNSET, headers: Dict[str, str] | None = None, name: str, head_sha: str, details_url: Unknown | str | None = UNSET, external_id: Unknown | str | None = UNSET, status: Unknown | Literal['queued', 'in_progress'] | None = UNSET, started_at: Unknown | datetime | None = UNSET, conclusion: Unknown | Literal['action_required', 'cancelled', 'failure', 'neutral', 'success', 'skipped', 'stale', 'timed_out'] | None = UNSET, completed_at: Unknown | datetime | None = UNSET, output: Unknown | ReposOwnerRepoCheckRunsPostBodyPropOutputType | None = UNSET, actions: Unknown | List[ReposOwnerRepoCheckRunsPostBodyPropActionsItemsType] | None = UNSET) -> Response[CheckRun]]" (reportUnknownMemberType)

• At POSITION 2:

error: Type of "installation" is partially unknown
    Type of "installation" is "Unknown | SimpleInstallation | None" (reportUnknownMemberType)

Investigation

First of all, those errors don't come up yet in VSCode when using pylance (microsoft/pylance-release#6153), for now only pyright reports them.

I think I pinpointed the issue to the use of Literal[UNSET] in several parts of the code. It's not valid to use a variable in Literal even if it references an actual literal value or enum member.

If I replace occurrences of Literal[UNSET] with Literal[Unset._UNSET] in several parts of the code (eg. here and here), the aforementioned errors disappear.
I'm unsure this is correct approach to properly fix those issues.

Thank you for creating this library, your work is greatly appreciated.

[yanyongyu]

I think this may be a bug of pyright, here is the smallest example:

from enum import Enum
from typing import Literal

class Foo(Enum):
    _FOO = "foo"


FOO = Foo._FOO  # type: Literal[Foo._FOO]

a: Literal[FOO]  # error: reportInvalidTypeForm
a: Literal[Foo._FOO]  # ok
a: Literal[Literal[Foo._FOO]]  # ok

I have report an issue to confirm whether this is the valid use case.

[fau-st]

Well, I'm not sure, this seems like an intentional change: microsoft/pyright#8318
mypy also behaves the same way: python/mypy#17493