google
BUG: pytype generates wrong annotation for built in function
With the following example pytype generates wrong annotations:
$ cat t.py
from os import chdir
from pathlib import Path
f = Path(__file__).resolve()
chdir(f)
$ pytype t.py
$ cat .pytype/pyi/t.pyi
# (generated with --quick)
import os
import pathlib
from typing import Union
Path: type[pathlib.Path]
f: pathlib.Path
def chdir(path: Union[bytes, int, str, os.PathLike[Union[bytes, str]]]) -> None: ...
where the built in os.chdir function expects str | bytes | os.PathLike[str] | os.PathLike[bytes].
However, pytpe genrates bytes | int | str | os.PathLike[bytes | str]], where the inclusion of int is wrong and the os.PathLike[Union[bytes, str]] is problematic because PathLike should be either PathLike[str] or PathLike[bytes].
This can't be intended behavior, right? How to fix that? This creates issues with our pre-commit because pyright picks up the .pytype folder and complains
error: Type "bytes | str" cannot be assigned to type variable "AnyStr_co@PathLike"
Type "bytes | str" is not assignable to constrained type variable "AnyStr_co@PathLike" (reportInvalidTypeArguments)
Is this a known issue, or is there a recommended fix?
This partially seems to be a typeshed issue. See https://github.com/python/typeshed/issues/13692
However, there also seems to be a pytype issue here.
When changing the typeshed annotation, pytype generates
def chdir(path: Union[bytes, str, os.PathLike[Union[bytes, str]]]) -> None: ...
and pyright keeps complaining. However, when changing the pytype generated code to
def chdir(path: Union[bytes, str, os.PathLike[bytes], os.PathLike[str]]) -> None: ...
pyright is fine and this also fits the definitiontion of
StrOrBytesPath: TypeAlias = str | bytes | PathLike[str] | PathLike[bytes]
in https://github.com/python/typeshed/blob/main/stdlib/_typeshed/init.pyi#L179
There thus seems to be an issue in the way pytype handles unions which should not be cobbled together.
This is not a typeshed issue but seems to be purely due to pytype doing something wrong.
