| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
| class ItemsView(MappingView, AbstractSet[tuple[_KT_co, _VT_co]], Generic[_KT_co, _VT_co]): | ||
| def __init__(self, mapping: SupportsGetItemViewable[_KT_co, _VT_co]) -> None: ... # undocumented | ||
| @classmethod | ||
| def _from_iterable(cls, it: Iterable[Any]) -> set[Any]: ... |
There was a problem hiding this comment.
Why not def [S](cls, it: Iterable[S]) -> set[S] ?
Sorry, something went wrong.
There was a problem hiding this comment.
Good call, updated to use Iterable[_S] -> set[_S]. Used the existing _S TypeVar since PEP 695 syntax isn't used elsewhere in typeshed.
Sorry, something went wrong.
| def _hash(self) -> int: ... | ||
| # Mixin methods | ||
| @classmethod | ||
| def _from_iterable(cls, it: Iterable[Any]) -> AbstractSet[Any]: ... |
There was a problem hiding this comment.
This should return Self, not any AbstractSet, since the implementation is return cls(it) and other methods on MutableSet that rely on this are annotated to return Self.
Sorry, something went wrong.
There was a problem hiding this comment.
Updated to AbstractSet[_S] for type preservation, but can't use Self here - KeysView and ItemsView override this to return set, not Self. Using Self on the base would make those overrides invalid. Also MutableSet.__ior__/__iand__ etc. don't actually call _from_iterable, they mutate in-place directly.
Sorry, something went wrong.
There was a problem hiding this comment.
Actually, the type we want here is more like def [S](cls, Iterable[S]) -> Self & AbstractSet[S], which is not expressible at the moment.
Sorry, something went wrong.
There was a problem hiding this comment.
So -> AbstractSet[S] seems like the best approximation atm.
Sorry, something went wrong.
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
|
Btw. in the original issue I posted a comment that this is probably a bad idea at the moment -- sorry I didn't mention it here earlier, I didn't realize this was a different account than the OP of #15298 |
Sorry, something went wrong.
|
So, cpython will not support _from_iterable on builtins.set. (python/cpython#144557) Therefore, the best we can do is put that definition into a if not TYPE_CHECKING block with a comment explaining the situation |
Sorry, something went wrong.
| @classmethod | ||
| def _from_iterable(cls, it: Iterable[_S]) -> AbstractSet[_S]: ... |
There was a problem hiding this comment.
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> AbstractSet[_S]: ... | |
| if not TYPE_CHECKING: | |
| # this method exists on collections.abc.Set, but since it is not | |
| # supported by builtins.set, we exclude it from static typing | |
| # see: cpython/issues/144557 and typeshed/issues/15298 | |
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> AbstractSet[_S]: ... |
Sorry, something went wrong.
| @classmethod | ||
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... |
There was a problem hiding this comment.
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... | |
| if not TYPE_CHECKING: | |
| # this method exists on collections.abc.ItemsView, but since it is not | |
| # supported by dict_items, we exclude it from static typing | |
| # see: cpython/issues/144557 and typeshed/issues/15298 | |
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... |
Sorry, something went wrong.
| @classmethod | ||
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... |
There was a problem hiding this comment.
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... | |
| if not TYPE_CHECKING: | |
| # this method exists on collections.abc.KeysView, but since it is not | |
| # supported by dict_keys, we exclude it from static typing | |
| # see: cpython/issues/144557 and typeshed/issues/15298 | |
| @classmethod | |
| def _from_iterable(cls, it: Iterable[_S]) -> set[_S]: ... |
Sorry, something went wrong.
I don't think we should start putting TYPE_CHECKING checks into stub files. I'd rather have these methods not in the stubs than introducing such an idiom in stub files. But as I mentioned in #15298, I'd rather add these methods unconditionally. |
Sorry, something went wrong.
|
Diff from mypy_primer, showing the effect of this PR on open source code: discord.py (https://github.com/Rapptz/discord.py)
- ...typeshed_to_test/stdlib/typing.pyi:1049: note: "update" of "TypedDict" defined here
+ ...typeshed_to_test/stdlib/typing.pyi:1055: note: "update" of "TypedDict" defined here
|
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks!
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
This PR adds _from_iterable to AbstractSet (returning AbstractSet[_S] to preserve element types while allowing subclasses that return set), and to KeysView/ItemsView which override it to return set[_S]. MutableSet inherits from AbstractSet so no separate definition is needed.
Fixes #15298.