Repository navigation
All instances of types.GenericAlias are iterable on Python 3.11+ #103450
Description
Activity
the runtime usually prefers to be lenient when it comes to typing constructs, leaving it to type checkers to point out invalid usage
I vote for this option!
My thinking at the time was that this could be useful for allowing something like
tuple[*Iterable[int]], or something related to the TypeVarDict idea that was recently brought up on typing-sig. I don't see a need to forbid this again, especially since we've already had a series of releases allowing it.It's probably not really a big deal, but one impact of this is that there's yet another way in which
collections.abc.Callableandtyping.Callableare slightly different from each other:>>> import collections.abc, typing >>> list(collections.abc.Callable[..., int]) [*collections.abc.Callable[..., int]] >>> list(typing.Callable[..., int]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '_CallableGenericAlias' object is not iterable
- changed the title
[-]All generic aliases are iterable on Python 3.11+[/-][+]All instances of `types.GenericAlias` are iterable on Python 3.11+[/+]on Apr 11, 2023 @AlexWaygood yes, this happens because most of the
typingconstructs directly inherit fromclass _NotIterable: """Mixin to prevent iteration, without being compatible with Iterable. That is, we could do: def __iter__(self): raise TypeError() But this would make users of this mixin duck type-compatible with collections.abc.Iterable - isinstance(foo, Iterable) would be True. Luckily, we can instead prevent iteration by setting __iter__ to None, which is treated specially. """ __slots__ = () __iter__ = None
Seems like there's little appetite for changing this
All generic aliases appear to be iterable on Python 3.11+, meaning you can do some fairly bizarre things that don't really make any sense:
This is due to the implementation of PEP 646 that was added in #31019 by @mrahtz. It was a deliberate decision at the time: 4aa94df is the commit in that PR branch that removes the restriction that only
tuplecan be unpacked (the commit was done in response to a review comment here: #31019 (comment)). However, there wasn't much discussion at the time.Do we want to stick with this behaviour, on the basis that the runtime usually prefers to be lenient when it comes to typing constructs, leaving it to type checkers to point out invalid usage? Or should this be considered a bug?