This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cybertreiber
Recipients cybertreiber, eric.smith
Date 2019-12-26.00:05:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
In-reply-to
Content
At runtime, we want to check whether objects adhere to a data protocol. This is not possible due to problematic interactions between ABC and @dataclass.

The attached file tests all relevant yet impossible cases. Those are:

1) A(object): Can't check due to "Protocols with non-method members don't support issubclass()" (as outlined in PEP 554)
2) B(ABC): "Can't instantiate abstract class B with abstract methods x, y"
3) C(Protocol): same as A or same as B if @property is @abstractmethod

The problem can be solved in two parts. First allowing to implement @abstractproperty in a dataclass (B). This doesn't involve typing and enables the expected use case of dataclass+ABC. I analysed this problem as follows:
Abstract properties evaluate to a default of property, not to dataclasses.MISSING. Hence, `dataclasses._init_fn` throws TypeError because of deriving from class vars without defaults.

Second, eliding the exception of @runtime_checkable Protocols with non-method members if and only if the the the protocol is in its MRO. I didn't think that through fully, but instantiation could e.g. fail for missing implementations as expected from ABC behaviour (see case D in attached file). I'm not sure about the runtime overhead of this suggestion.
History
Date User Action Args
2019-12-26 00:05:40cybertreibersetrecipients: + cybertreiber, eric.smith
2019-12-26 00:05:40cybertreibersetmessageid: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
2019-12-26 00:05:40cybertreiberlinkissue39134 messages
2019-12-26 00:05:39cybertreibercreate