Skip to content

Should Missing type implicitly allow None? #47

Closed
@frankie567

Description

@frankie567

GitHub API schema is not always consistent with the required and nullable fields. Currently, this is solved by maintaining the schema_overrides table and report them to GitHub (hoping they'll solve it).

Unfortunately, this is fragile and can break code if GitHub suddenly decides to pop-up nullable fields in its API response. For example, this was working well some days ago:

from githubkit import GitHub
github = GitHub()
r = github.rest.orgs.get("frankie567-test-org-renamed")
r.parsed_data

But not anymore:

Traceback (most recent call last):
File "", line 1, in
File "/Users/fvoron/Development/githubkit/githubkit/response.py", line 50, in parsed_data
return parse_raw_as(self._data_model, self._response.content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "pydantic/tools.py", line 82, in pydantic.tools.parse_raw_as
File "pydantic/tools.py", line 38, in pydantic.tools.parse_obj_as
File "pydantic/main.py", line 341, in pydantic.main.BaseModel.init
pydantic.error_wrappers.ValidationError: 2 validation errors for ParsingModel[OrganizationFull]
root -> name
none is not an allowed value (type=type_error.none.not_allowed)
root -> blog
none is not an allowed value (type=type_error.none.not_allowed)


That's why I was wondering if we could tweak the Missing type so it implicitly allows None. So basically this part:

Missing: TypeAlias = Union[Literal[UNSET], T]

becomes:

Missing: TypeAlias = Union[Literal[UNSET], T, None]

Admittedly, this is not perfectly accurate regarding the schema but it seems more bullet-proof while GitHub make up their mind about this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions