aha79

Hmm, but what is the alternative? Not supporting dataclasses would not be very useful - at least not for me. Hooks without any type resolving before will just generate an...

I understand your concern regarding mantainability. However I would argue having a more symmetric way of handling dataclasses and attrs classes is cleaner and needs less maintenance effort. For instance:...

Could it also be that in https://github.com/python-attrs/cattrs/commit/a4282724a47df8ac9f5a9c8069dc49160cae152d cattr/gen.py and cattrs/gen.py are accentially swapped?

The primary reason to implement `resolve_types` for all types is that it is needed inside cattr for `ForwardRef` resolution and not to provide it to the user (that would be...

> Another option would be improving some of the cattrs APIs to be more customizable, which would be useful for other things too. Could you elaborate on that?

Okay, I see. I confirm, this works. However now I try to get this one-line recursive type YY = typing.List[ typing.Tuple[typing.Optional[YY],int] ] to work. Unfortunately, this generates a "NameError" even...

My preliminary conclusions after I thought about this issue: - Even with PEP 563 enabled there are situations where ForwardRefs (or quoted types) are needed to correctly describe a situation....

I am not sure if we could really evaluate the ForwardRefs, as it would probably trigger the hashing issue with recursive types. So I guess we need to keep the...

@Tinche I think this is a workable solution. Sidenote: You do not need to explicitly construct ForwardRef, this is done automatically :-). Just write `Optional['YY']` However if we accept explicitly...

This seems to do the job ``` c = cattr.GenConverter() def _gen_forwardref_hook(type): type._evaluate(None, None, set()) return lambda v, t: c.structure(v, t.__forward_value__) c.register_structure_hook_factory( lambda t: t.__class__ is typing.ForwardRef, _gen_forwardref_hook ) ```...