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
There is a regression in unstructuring of statically typed Any field in versions published after 1.1.2. It returns the value as-is, regardless of whether the runtime type is an attrs class.
The behavior then stays consistent from 1.4.0 onward. We are still slowly updating our application code to use our internal libraries which are now using cattrs 22.2.0, which is how I came across this. We have a very specific use case where using generics would be impractical; we're just now moving from 3.7 to 3.9 and therefore can't use 3.11's variadic generics and defining a handful of TypeVars would be unsightly.
The text was updated successfully, but these errors were encountered:
xaviergmail
changed the title
Regression of unstructuring ty.Any based on runtime types
Regression of unstructuring typing.Any based on runtime types
Nov 9, 2022
Any as passthrough when structuring is really the only option. It would be very surprising to do anything else.
That is not the case when unstructuring, though. At that point, you have the runtime type available. You could choose to unstructure that object, as your example shows. It is surprising behavior to not unstructure when asked to, when that is a straightforward possibility.
Description
There is a regression in unstructuring of statically typed
Any
field in versions published after1.1.2
. It returns the value as-is, regardless of whether the runtime type is an attrs class.What I Did
Using the following code:
I ran the following:
cattrs 1.1.2
List[Any]
andAny
get unstructured fine.cattrs 1.2.0
List[Any]
gets unstructured but notAny
cattrs 1.4.0 onwards
GenConverter no longer unstructures
Any
fieldsBaseConverter retained the inconsistent 1.2.0 behavior
The behavior then stays consistent from 1.4.0 onward. We are still slowly updating our application code to use our internal libraries which are now using cattrs 22.2.0, which is how I came across this. We have a very specific use case where using generics would be impractical; we're just now moving from 3.7 to 3.9 and therefore can't use 3.11's variadic generics and defining a handful of TypeVars would be unsightly.
The text was updated successfully, but these errors were encountered: