<@U0265RTUJ5B> <@UNZB4NW3S> would you guys be open...
# flytekit
e
@high-accountant-32689 @freezing-airport-6809 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
h
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.
e
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.
šŸ‘ 1
h
cc: @thankful-minister-83577, just in case you can think of an edge case.
@elegant-australia-91422, after some deliberation we feel like this is reasonable. I'm going to merge and generate a beta release for you try out.
šŸ™ 1
e
Amazing, thanks @high-accountant-32689!
h
@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
154 Views