get_origin of typing.Iterable returns collections.abc.Iterable

In [1]: import typing_inspect; import typing

In [2]: t = typing.Iterable[int]

In [3]: typing_inspect.get_origin(t)
Out[3]: collections.abc.Iterable

I would expect it to return typing.Iterable instead.

Why? I am using the get_origin and get_args to take apart to walk the type tree, transforming certain nodes and collecting some data (to match a template tree against an actual tree). Similar to something you would do in the AST package or with any other traversal of a nested data structure.

This means I want to be be able to recursively fold over the types, which means I have to be able to deconstruct them and put them back together again. Since collections.abc.Iterable[int] is invalid, this breaks this use case.

This is likely the same issue as https://github.com/ilevkivskyi/typing_inspect/issues/27, but I think I have a slightly different use case. If you have general suggestions on better ways to do this kind of fold, instead of using get_origin and get_args, I am welcome to suggestions.

cc @tonyfast who is also doing some type traversal stuff.

[Stewori]

I encountered the same issue on supporting Python 3.7 in pytypes. I tried to resolve it by an internal map, e.g. origin_dict[collections.abc.Iterable] == typing.Iterable but discarded that because it only shifted my core issue: I actually needed a way to tell that e.g. List[T] is a subtype of MutableSequence[T] and so on. This became a hassle in the new typing as well (or even worse). So far I came up with this hackish solution: https://github.com/Stewori/pytypes/blob/master/pytypes/type_util.py#L105 but I will probably have to rewrite it again. This is only the first step to make things somehow work again. If it helps you, you can access it as pytypes.type_bases (avaible only in unreleased master branch as of this writing).

[ilevkivskyi]

(I will not have time to work on this any time soon, but PRs are wellcome 😃)