Skip to content

set operations and unpacking #14259

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
Molkree opened this issue Dec 6, 2022 · 4 comments · Fixed by #18943
Closed

set operations and unpacking #14259

Molkree opened this issue Dec 6, 2022 · 4 comments · Fixed by #18943
Labels
bug mypy got something wrong

Comments

@Molkree
Copy link

Molkree commented Dec 6, 2022

Bug Report

Error on a valid code.

To Reproduce

sets = map(set[str], ["aaa", "abb", "acc"])
intersection = set[str].intersection(*sets)

mypy Playground

Actual Behavior

Argument 1 to "intersection" of "set" has incompatible type "*map[Set[str]]"; expected "Set[_T]" [arg-type]

Your Environment

  • Mypy version used: 0.991
  • Mypy command-line flags: --strict (it's present without strict checking as well)
  • Mypy configuration options from mypy.ini (and other config files): None
  • Python version used: 3.11

This issue is present for a bunch of other set methods like union and difference (I guess all of them that accept *s: Iterable[T]).
Possibly related #9706.

@Molkree Molkree added the bug mypy got something wrong label Dec 6, 2022
@Kein
Copy link

Kein commented Jan 19, 2023

Same:

@dataclass
class StatsEntry:
    val0: int
    val1: int
    val2: int

    def __post_init__(self) -> None:
        for field in dcfields(self):
            value = getattr(self, field.name)
            setattr(self, field.name, field.type(value))


entry = line.rstrip().split(',')
stat = StatsEntry(*entry) #type: ignore
# Argument 1 to "StatsEntry" has incompatible type "*List[str]"; expected "int"  [arg-type]mypy(error)

@randolf-scholz
Copy link
Contributor

randolf-scholz commented Aug 3, 2023

Another example (mypy-playground):

from typing import Mapping, Any

def joint_keys(*dicts: Mapping[str, Any]) -> set[str]:
    """Find joint keys in collection of dictionaries."""
    return set.intersection(*map(set, dicts))    # ✘ [arg-type]

def joint_keys2(*dicts: Mapping[str, Any]) -> set[str]:
    """Find joint keys in collection of dictionaries."""
    dicts_keys: map[set[str]] = map(set, dicts)  # ✔
    return set.intersection(*dicts_keys)         # ✔

pyright raises no errors, so likely an issue with mypy (and not with stubs).

EDIT: It is fixed using the --new-type-inference flag on master branch

https://mypy-play.net/?mypy=master&python=3.11&gist=95765a01a9543509a1c740f4f9448397&flags=new-type-inference

@Molkree
Copy link
Author

Molkree commented Dec 22, 2024

@randolf-scholz your example raises no errors since mypy 1.7 (released Nov 10, 2023) where new type inference was enabled by default.

My original repro raises no errors since mypy 1.14 (released Dec 19, 2024).

@Molkree Molkree closed this as completed Dec 22, 2024
@Molkree
Copy link
Author

Molkree commented Jan 5, 2025

Original repro raises an error once again in mypy 1.14.1

Reason is, mypy stopped raising in 1.14.0 due to a bug (inferring Any instead of a more precise type).

So this issue wasn't really fixed, reopening.

@Molkree Molkree reopened this Jan 5, 2025
cdce8p pushed a commit to cdce8p/mypy that referenced this issue May 31, 2025
Fixes python#18024
Fixes python#18706
Fixes python#17734
Fixes python#15097
Fixes python#14814
Fixes python#14806
Fixes python#14259
Fixes python#13041
Fixes python#11993
Fixes python#9585
Fixes python#9266
Fixes python#9202
Fixes python#5481

This is a fourth "major" PR toward
python#7724. This is one is
watershed/crux of the whole series (but to set correct expectations,
there are almost a dozen smaller follow-up/clean-up PRs in the
pipeline).

The core of the idea is to set current type-checker as part of the
global state. There are however some details:
* There are cases where we call `is_subtype()` before type-checking. For
now, I fall back to old logic in this cases. In follow up PRs we may
switch to using type-checker instances before type checking phase (this
requires some care).
* This increases typeops import cycle by a few modules, but
unfortunately this is inevitable.
* This PR increases potential for infinite recursion in protocols. To
mitigate I add: one legitimate fix for `__call__`, and one temporary
hack for `freshen_all_functions_type_vars` (to reduce performance
impact).
* Finally I change semantics for method access on class objects to match
the one in old `find_member()`. Now we will expand type by instance, so
we have something like this:
  ```python
  class B(Generic[T]):
      def foo(self, x: T) -> T: ...
  class C(B[str]): ...
  reveal_type(C.foo)  # def (self: B[str], x: str) -> str
  ```
FWIW, I am not even 100% sure this is correct, it seems to me we _may_
keep the method generic. But in any case what we do currently is
definitely wrong (we infer a _non-generic_ `def (x: T) -> T`).

---------

Co-authored-by: hauntsaninja <[email protected]>
Co-authored-by: Shantanu <[email protected]>
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

Successfully merging a pull request may close this issue.

3 participants