@high-accountant-32689 @freezing-airport-6809 would you guys be open to swapping steps 3 & 4 when resolving TypeTransformers? Our use-case is the following: • We have internal tooling to generate dataclasses from OpenAPI and/or Conjure specifications. These generated dataclasses all include the

Generated

mixin. These dataclasses are all guaranteed to have a `to_dict`/`from_dict` method • We'd like to register a single TypeTransformer to serialize any generated dataclass (ideally we'd like to register a TypeTransformer for

Generated

) Given the current implementation, we're not able to do this since FlyteKit will always perform the

dataclasses.is_dataclass

check first before walking the inheritance hierarchy.

let me think about it. I can't think of any cons off the top of my head. Also I'm fairly certain that assuming unit tests are going to pass.

Yeah, I also thought about it for a bit and think this is a purely additive change (since any registered TypeTransformers for a class in a dataclass' inheritance hierarchy would be ignored currently). However, if we land this PR and were to revert it in the future, that'd be a breaking change.

cc: @thankful-minister-83577, just in case you can think of an edge case.

Amazing, thanks @high-accountant-32689!

@elegant-australia-91422, I just created a new flytekit release containing this change (and also the default deck renderer for pandas dataframes): https://github.com/flyteorg/flytekit/releases/tag/v1.2.2b0