Skip to content

TypeVar not compatible with object #13689

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Dreamsorcerer opened this issue Sep 19, 2022 · 7 comments
Closed

TypeVar not compatible with object #13689

Dreamsorcerer opened this issue Sep 19, 2022 · 7 comments
Labels
bug mypy got something wrong

Comments

@Dreamsorcerer
Copy link
Contributor

In order to keep code type safe and declare that my code will work with any type, I have used object. But, when trying to use a TypeVar in another part of the code, it complains that it is incompatible with object.

My code looks roughly like:

jobs: Set[Job[object]] = set()

async def spawn(self, coro: Coroutine[object, object, _T]) -> Job[_T]:
    jobs.add(job)

I'm getting:

error: Argument 1 to "add" of "set" has incompatible type "Job[_T]"; expected "Job[object]"  [arg-type]

I don't think it's an invariance problem..

@Dreamsorcerer Dreamsorcerer added the bug mypy got something wrong label Sep 19, 2022
@JelleZijlstra
Copy link
Member

Your code sample is incomplete, but that does look like an invariance problem. If Job is invariant in its type parameter, a Job[_T] is not compatible with a Job[object].

@Dreamsorcerer
Copy link
Contributor Author

One day I'll get my head round covariance properly. :P

After making the TypeVar covariant, I still have one more error in:

_T = TypeVar("_T", covariant=True)
task: asyncio.Task[_T]
_failed_tasks: asyncio.Queue[Optional[asyncio.Task[object]]] = asyncio.Queue()
_failed_tasks.put_nowait(task)  #  Argument 1 to "put_nowait" of "Queue" has incompatible type "Task[_T]"; expected "Optional[Task[object]]"  [arg-type]

That seems pretty much the same to me as the previous problem. I'll have the real code up in a PR in a couple of days, if it's useful to look at.

@JelleZijlstra
Copy link
Member

The variance you set there doesn't do anything. What matters is how Task is declared in the stubs, and the TypeVar is invariant there: https://github.com/python/typeshed/blob/6ca80d340ef16714e61284df8338dac91479aa79/stdlib/asyncio/tasks.pyi#L268

@Dreamsorcerer
Copy link
Contributor Author

OK, is that correct though?

I'm looking at the list example at: https://mypy.readthedocs.io/en/stable/generics.html#variance-of-generics
But, I'm not seeing a reason that Task would need to be invariant. It's not a mutable container, and I can't think of anything else that would break it.

@JelleZijlstra
Copy link
Member

It does seem like we could make it covariant. We'd also have to make the base class asyncio.Future covariant in its type parameter.

@Dreamsorcerer
Copy link
Contributor Author

python/typeshed#8781

@hauntsaninja
Copy link
Collaborator

Hmm asyncio.Future is mutable, if you made it covariant set_result would be unsound

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong
Projects
None yet
Development

No branches or pull requests

3 participants