8000 Tuple[...] should be compatible with Iterable[...] and Sequence[...] · Issue #296 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

Tuple[...] should be compatible with Iterable[...] and Sequence[...] #296

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.

Sign up for GitHub

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

Jump to bottom
Closed
JukkaL opened this issue Jul 15, 2014 · 7 comments · Fixed by #8004
Closed

Tuple[...] should be compatible with Iterable[...] and Sequence[...] #296

JukkaL opened this issue Jul 15, 2014 · 7 comments · Fixed by #8004
Labels
feature

Comments

@JukkaL
Copy link
Collaborator
JukkaL commented Jul 15, 2014

Currently, Tuple[int, int] is not compatible with Iterable[int] and Sequence[int], but it should obviously be. Also, update type join to support this (join of Tuple[int, int] and Tuple[int] should be Sequence[int]).

For example, this program is rejected:

from typing import Iterable
def f(x: Iterable[int]) -> None: pass
f([1,2])  # OK
f((1,2))  # Argument 1 to "f" has incompatible type "Tuple[int, int]"

See also #184 (it's very closely related).
@JukkaL
Copy link
Collaborator Author
JukkaL commented Jul 25, 2014

Implementation waiting to be merged in the type-system-features branch: afe4c57

@JukkaL JukkaL closed this as completed Jul 25, 2014
@terrisgit
Copy link
terrisgit commented Apr 5, 2018 •
edited
Loading

This problem still exists in 2018... mypy==.580

async def execute_update(query: str, query_args: Sequence[Any]=None)->None:
pass

await DbExecutor.execute_update("select 1", (5))

error: Argument 2 to "execute_update" has incompatible type "int"; expected "Optional[Sequence[Any]]"

Resolution is to use [5] instead of (5) ... which is not what I want

Why is this closed?

@Michael0x2a
Copy link
Collaborator

@terrisgit -- (5) isn't actually a tuple -- that expression is equal to just 5.

If you instead pass in (5,), everything typechecks.

@gvanrossum
Copy link
Member

Gotta give points for the attitude.

@terrisgit
Copy link

Thanks for the education!
8000

@user-name-name
Copy link

I have a next case: the result of one function is Dict[str, Tuple[str, ...]], the argument of another one is Dict[str, Sequence[str]]. So when we use use the result of the first function as the argument of the second, we got "Argument has incompatible type Dict[str, Tuple[str, ...]]"; expected "Dict[str, Sequence[str]]". Is it valid?

@ilevkivskyi
Copy link
Member

@user-name-name Mypy is correct, Dict is invariant https://mypy.readthedocs.io/en/latest/generics.html#variance-of-generic-types

@msullivan msullivan mentioned this issue Nov 23, 2019
Merged
msullivan added a commit that referenced this issue Nov 23, 2019
@msullivan
[mypyc] Add a mypyc_attr to support interpreted children
50b45ce 
This operates by generating a "shadow vtable" containing pointers to
glue methods that dispatch to the appropriate method via the C API. We
then install those shadow vtables in interpreted subclasses so that
overridden methods will be called.

This does not support directly inheriting from traits, which I think
will require generating vtables dynamically (and maybe some more
nonsense too.)

Closes #296. (Though I will file a follow-up for traits.)
msullivan added a commit that referenced this issue Nov 28, 2019
@msullivan
[mypyc] Add a mypyc_attr to support interpreted children
c1dce83 
This operates by generating a "shadow vtable" containing pointers to
glue methods that dispatch to the appropriate method via the C API. We
then install those shadow vtables in interpreted subclasses so that
overridden methods will be called.

This does not support directly inheriting from traits, which I think
will require generating vtables dynamically (and maybe some more
nonsense too.)

Closes #296. (Though I will file a follow-up for traits.)
msullivan added a commit that referenced this issue Nov 28, 2019
@msullivan
[mypyc] Add a mypyc_attr to support interpreted subclasses (#8004)
37a2b9a 
This operates by generating a "shadow vtable" containing pointers to
glue methods that dispatch to the appropriate method via the C API. We
then install those shadow vtables in interpreted subclasses so that
overridden methods will be called.

This does not support directly inheriting from traits, which I think
will require generating vtables dynamically (and maybe some more
nonsense too.)

Closes #296.
@bfelbo bfelbo mentioned this issue Apr 21, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[mypyc] Add a mypyc_attr to support interpreted children python/mypy
6 participants
@JukkaL @Michael0x2a @gvanrossum @terrisgit @ilevkivskyi @user-name-name
0