<@U0265RTUJ5B> <@UNZB4NW3S> would you guys be open...
# flytekit
r
@Eduardo Apolinario (eapolinario) @Ketan (kumare3) would you guys be open to swapping steps 3 &amp; 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.
I've already put together a branch to make this change, but wanted to check if there were any other considerations before opening the PR Edit: just opened it here. Happy to discuss any relative pros/cons or other concerns on the PR https://github.com/flyteorg/flytekit/pull/1239
e
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.
r
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.
e
cc: @Yee, just in case you can think of an edge case.
@Rahul Mehta, after some deliberation we feel like this is reasonable. I'm going to merge and generate a beta release for you try out.
r
Amazing, thanks @Eduardo Apolinario (eapolinario)!
e
@Rahul Mehta, 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
104 Views