[GitHub] [beam] kennknowles opened a new issue, #18788: Incorrect coder inference for List and Tuple typehints.

[GitBox <gi...@apache.org>]

kennknowles opened a new issue, #18788:
URL: https://github.com/apache/beam/issues/18788

   We seem to use a FastPrimitivesCoder for List and Tuple typehints with homogenous element types, and fail to do the type checking:
   
   ```
   
   inputs = (1, "a string")
   coder = typecoders.registry.get_coder(typehints.Tuple[int, str])
   print(type(coder))
   # <class 'apache_beam.coders.coders.TupleCoder'>
   encoded = coder.encode(inputs) 
   # Fails: TypeError:
   an integer is required - correct behaviour
   
   coder = typecoders.registry.get_coder(typehints.Tuple[int,
   ...]) # A tuple of integers.
   print(type(coder)) # <class 'apache_beam.coders.coders.FastPrimitivesCoder'>
   - wrong coder?
   encoded = coder.encode(inputs)
   # No errors - incorrect behavior.
   
   coder = typecoders.registry.get_coder(typehints.List[int])
   # A list of integers.
   print(type(coder)) # <class 'apache_beam.coders.coders.FastPrimitivesCoder'>
   - wrong coder?
   encoded = coder.encode(inputs)
   # No errors - incorrect behavior.
   ```
   
   
   Imported from Jira [BEAM-4441](https://issues.apache.org/jira/browse/BEAM-4441). Original Jira may contain additional context.
   Reported by: tvalentyn.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@beam.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org