Open AstraLuma opened 6 days ago
Sorry you had a bad experience using cattrs!
Let me try organizing my thoughts.
The most immediate thing is that your code example isn't correct - a string is not a valid value for a field of an enum type.
One of the main ideas of cattrs is this concept of validation at the edges - we do work when data enters the system, and only then. Inside the system you're expected to use a type checker, unit tests or whatever other means of ensuring correctness. This assumption is why cattrs does next to no validation when unstructuring - it's assuming the data is correct and goes for speed. This is what's been biting you here; no explicit validation means bad error messages.
That said, some codebases might not be able to ensure this, or maybe they rely on libraries that can't ensure this, or something else. I wouldn't change the default behavior, but I think implementing a strategy, that can be applied to a converter and that would enable more validation when unstructuring, would be a good idea. Especially since users would be free to, for example, apply the strategy conditionally - maybe when running in debug mode, maybe when running unit tests, maybe when running in a staging environment, maybe always.
I think this would be a good addition to cattrs.
Description
Use an enum's value as the default of a class (instead of the enum reference) causes an unhelpful backtrace.
tbh, I'm not entirely sure what the fix here is, but based on how much effort I put into finding this mistake, I think there's room for some improvement in developer experience.
What I Did
This code:
Causes this error:
which is obvious when reduced, but in my case, the usage was spread out between a definition, usage, and a wrapping library, so it looked more like: