Replying to break the silence - in Java the DoFn is done according to the
main output type, then phantom types on the output tag are used to make
sure non-main outputs are type safe (I wouldn't expect this sort of
technique in Python)
Anyone who is more expert in Beam Python typing stuff? +Jack Mc
I wonder, then, if the phantom type trick might be less "extra burden for
type safety" and more unambiguously helpful. It might looks something like
this (I'm sure someone has written how to do this in Python properly but
I'm just winging it)
class OutputTag[T]:
# a string, basically, and I will
Today, you can abbreviate arguments in Beam Python. This is generally
convenient since you can do things like specify `--r` instead of `--runner`,
and Beam will infer your intent.
Unfortunately, it also has unintended side effects. For example, specifying
`--u` will impact not just `--update`, but
Ah yeah, unfortunately tagged outputs currently inherit the output typing
of the parent DoFn. It's a bit of a pain, since a "correct" output type
hint becomes the union of all of the possible output types of the DoFn (and
becomes really hard to scope back down for DoFns that consume specific
tagged
