This repository has been archived by the owner on Jul 3, 2023. It is now read-only.
Support Generics #39
Assignees
Labels
enhancement
New feature or request
Comments
skrawcz
added a commit
that referenced
this issue
Mar 22, 2022
We were not doing a great job ensuring that the issubclass check would not break. So this changes that, and adds more use of the typing_inspect module. We'll have to test this for compatibility to ensure things work with 3.6. So I specifically created a dedicated function to encapsulate this type checking logic. To handle generics, I did a very basic approximation that should work for most use cases. E.g. list vs typing.List, or typing.Dict vs typing.Mapping. In terms of precedence, the param_type is the input parameter type annotated on the function, and the requested_param_type is coming from the output of an upstream function. Thus, the param_type should be the super type if there is one, not the other way around.
12 tasks
skrawcz
added a commit
that referenced
this issue
Mar 23, 2022
We were not doing a great job ensuring that the issubclass check would not break. So this changes that, and adds more use of the typing_inspect module. We'll have to test this for compatibility to ensure things work with 3.6. So I specifically created a dedicated function to encapsulate this type checking logic. To handle generics, I did a very basic approximation that should work for most use cases. E.g. list vs typing.List, or typing.Dict vs typing.Mapping. In terms of precedence, the param_type is the input parameter type annotated on the function, and the requested_param_type is coming from the output of an upstream function. Thus, the param_type should be the super type if there is one, not the other way around.
skrawcz
added a commit
that referenced
this issue
Mar 23, 2022
We were not doing a great job ensuring that the issubclass check would not break. So this changes that, and adds more use of the typing_inspect module. We'll have to test this for compatibility to ensure things work with 3.6. So I specifically created a dedicated function to encapsulate this type checking logic. To handle generics, I did a very basic approximation that should work for most use cases. E.g. list vs typing.List, or typing.Dict vs typing.Mapping. In terms of precedence, the param_type is the input parameter type annotated on the function, and the requested_param_type is coming from the output of an upstream function. Thus, the param_type should be the super type if there is one, not the other way around.
skrawcz
added a commit
that referenced
this issue
Mar 23, 2022
We were not doing a great job ensuring that the issubclass check would not break. So this changes that, and adds more use of the typing_inspect module. We'll have to test this for compatibility to ensure things work with 3.6. So I specifically created a dedicated function to encapsulate this type checking logic. To handle generics, I did a very basic approximation that should work for most use cases. E.g. list vs typing.List, or typing.Dict vs typing.Mapping. In terms of precedence, the param_type is the input parameter type annotated on the function, and the requested_param_type is coming from the output of an upstream function. Thus, the param_type should be the super type if there is one, not the other way around.
skrawcz
added a commit
that referenced
this issue
Mar 23, 2022
We were not doing a great job ensuring that the issubclass check would not break. So this changes that, and adds more use of the typing_inspect module. We'll have to test this for compatibility to ensure things work with 3.6. So I specifically created a dedicated function to encapsulate this type checking logic. To handle generics, I did a very basic approximation that should work for most use cases. E.g. list vs typing.List, or typing.Dict vs typing.Mapping. In terms of precedence, the param_type is the input parameter type annotated on the function, and the requested_param_type is coming from the output of an upstream function. Thus, the param_type should be the super type if there is one, not the other way around.
|
I'm going to close this issue. 1.5.0 will have pretty decent support. It might miss an edge case or two, but we'll fix/assess support on a case by case basis going forward. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
Return/input types of
Tuple[str, str], for example, don't work.Describe the solution you'd like
We should have sophisticated subclass checking.
Describe alternatives you've considered
Adding an option to bypass compile-time type checking (🤮 )
Additional context
Creating metaflow examples and they'd be a lot more self-documenting this way.
The text was updated successfully, but these errors were encountered: