[
https://issues.apache.org/jira/browse/BEAM-8156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124303#comment-17124303
]
Udi Meiri edited comment on BEAM-8156 at 6/2/20, 8:47 PM:
----------------------------------------------------------
Current state is that internal types will continue to be used in the
IOTypeHints container and the 3 places in the original description.
Perhaps this will change if we implement type checking on Python's typing
module types, or to use an external type checking library (such as pytypes).
In this case, we would have to solve the pickling issue somehow (either write a
serializer or omit them -- how does standard pickling handle __annotations__?).
was (Author: udim):
Current thoughts are that internal types will continue to be used in the
IOTypeHints container and the 3 places in the original description.
Perhaps this will change if we rewrite these 3 places to work on Python's
typing module types, or to use an external type checking library (such as
pytypes).
In this case, we would have to solve the pickling issue somehow (either write a
serializer or omit them -- how does standard pickling handle __annotations__?).
> Finish migration to standard Python typing
> ------------------------------------------
>
> Key: BEAM-8156
> URL: https://issues.apache.org/jira/browse/BEAM-8156
> Project: Beam
> Issue Type: Improvement
> Components: sdk-py-core
> Reporter: Robert Bradshaw
> Assignee: Udi Meiri
> Priority: P2
> Labels: stale-assigned
> Original Estimate: 504h
> Time Spent: 1h 40m
> Remaining Estimate: 502h 20m
>
> We should migrate all Python uses of types to the standard typing module, and
> make the typehints.* ones aliases of the Python ones.
>
> There are three places where we use custom typehints behavior:
> (1) is_compatible_with
> (2) bind_type_variables/match_type_variables
> (3) trivial type inference.
>
> I would propose that each of these be adapted to a (internal) public
> interface that accepts and returns standard typing types, and internally
> converts to our (nowhere else exposed) typehints types, performs the logic,
> and converts back. Each of these in turn can then be updated, as needed and
> orthogonally, to operate on the typing types natively (possibly via deference
> to a third-party library).
>
> I think coder inference could be easily adopted to use typing types directly,
> but it may be a fourth place where we do internal conversion first. Another
> gotcha is special care may need to be taken if we ever need to pickle these
> types (which IIRC may have issues).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
