@george-zubrienko I understand that you had not planned to tackle this issue before v1 and am aware of the discussions in Issue #458 as well.
As mentioned by @USSX-Hares, there's a possibility PEP-649 ends up superseding PEP-563. However, a decision still has to be made
In the meantime, the inability to use CatchAll is a major blocker for the full adoption of dataclasses_json in my team as we
rely heavily on type hints and have no other option but to postpone their evaluation through from __future__ import annotations.
The proposed solution relies on typing.get_type_hints() (as suggested by @estyxx) instead of field.type (whose type depends on whether or not from __future__ import annotations is used)
The globals associated with the decorated class cls : Type[A] are gathered using vars(sys.modules[cls.__module__]), as recommended in the PEP563- Resolving Type Hints at Runtime section.
This PR addresses Issue #382
@george-zubrienko I understand that you had not planned to tackle this issue before v1 and am aware of the discussions in Issue #458 as well.
As mentioned by @USSX-Hares, there's a possibility PEP-649 ends up superseding PEP-563. However, a decision still has to be made
In the meantime, the inability to use
CatchAll
is a major blocker for the full adoption ofdataclasses_json
in my team as we rely heavily on type hints and have no other option but to postpone their evaluation throughfrom __future__ import annotations
.The proposed solution relies on
typing.get_type_hints()
(as suggested by @estyxx) instead offield.type
(whose type depends on whether or notfrom __future__ import annotations
is used)The globals associated with the decorated class
cls : Type[A]
are gathered usingvars(sys.modules[cls.__module__])
, as recommended in the PEP563- Resolving Type Hints at Runtime section.