You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that custom time hooks are applied to deserialized values when hooks for union types are defined. I think this is a bug.
To Reproduce
The following is a contrived example demonstrating the behavior, the code base I'm observing this in is more complex. In the example, it probably would work to simply omit the type hook for Union[Foo, Bar], but that won't work in the code base I think.
I'm declaring two types Foo and Bar with custom type hooks to get the following mapping:
"#123" -> Foo(id=123)
"abc" -> Bar(name='abc')
For the type Union[Foo, Bar], I'm declaring another custom type hook that looks for a # to decide on the type to return.
As you can see, after _read_foo_or_bar() has deserialized the value, the value is passed to both _read_foo() and _read_bar(), leading to result Bar(name=Foo(id=123)), which doesn't match the declared types and is surprising. This looks like a bug to me.
Expected behavior
IMHO, after applying the type hook _read_foo_or_bar(), the value should be used as-is and not processed further. I.e. I would expect the following output:
Describe the bug
It seems that custom time hooks are applied to deserialized values when hooks for union types are defined. I think this is a bug.
To Reproduce
The following is a contrived example demonstrating the behavior, the code base I'm observing this in is more complex. In the example, it probably would work to simply omit the type hook for
Union[Foo, Bar]
, but that won't work in the code base I think.I'm declaring two types
Foo
andBar
with custom type hooks to get the following mapping:"#123"
->Foo(id=123)
"abc"
->Bar(name='abc')
For the type
Union[Foo, Bar]
, I'm declaring another custom type hook that looks for a#
to decide on the type to return.When running this, I get the following output:
As you can see, after
_read_foo_or_bar()
has deserialized the value, the value is passed to both_read_foo()
and_read_bar()
, leading to resultBar(name=Foo(id=123))
, which doesn't match the declared types and is surprising. This looks like a bug to me.Expected behavior
IMHO, after applying the type hook
_read_foo_or_bar()
, the value should be used as-is and not processed further. I.e. I would expect the following output:Environment
The text was updated successfully, but these errors were encountered: