-
Notifications
You must be signed in to change notification settings - Fork 35
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
get_origin of typing.Iterable returns collections.abc.Iterable #36
Comments
I encountered the same issue on supporting Python 3.7 in pytypes. I tried to resolve it by an internal map, e.g. |
@Stewori Thanks for the reference. Luckily with I would love to eventually factor out all the type analysis it is doing and contribute it to something like |
Currently I too use an internal map in This may be privately available in from typing_inspect._extra.get_typing import get_typing
def get_origin_old(type_):
return get_typing(type_)[0] |
For reference python/cpython#13685 was just merged that adds |
Looking at the changes, that does not seem to address the issue discussed here, nor the somewhat related issue I have with getting the generic base type. Correct me if I overlook something -- what do you mean by "normalizes the return type"?
Sure! Various stuff is already there, feel free to open feature requests or contribute something. It is meant as a toolbox for these things that are beyond scope of typing_inspect.
It occurred to me, in pytypes there is also still this map https://github.com/Stewori/pytypes/blob/master/pytypes/type_util.py#L77, originally used for backwards lookup of the type from its |
See the change in the docs: I believe that is a similar/same issue as this one, because it adds a
|
Okay, then "normalization" refers exactly to the opposite of what is desired in this issue. One would need a way to opt out of the normalization. |
Yep. Or have a seperate |
Since now |
(I will not have time to work on this any time soon, but PRs are wellcome :-)) |
I would expect it to return
typing.Iterable
instead.Why? I am using the
get_origin
andget_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 #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
andget_args
, I am welcome to suggestions.cc @tonyfast who is also doing some type traversal stuff.
The text was updated successfully, but these errors were encountered: