[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: In the example, it should be `int`, right? Anyway, the bug tracker is not a good place to get questions answered. Since this is mostly about type checking, I recommend that you try this Gitter instance: https://gitter.im/python/typing --

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: In that case, what should the getter return? It doesn't know about the implementation of x. Maybe I'm not getting the idea behind adding getters/setters. -- ___ Python tracker

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: No doubt because your getter returns None. -- ___ Python tracker ___ ___ Python-bugs-list

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: This results in E(x=None). I'd need to look into that to understand why. -- Added file: https://bugs.python.org/file48817/dc2_repro.py ___ Python tracker

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: Try adding a setter to the base class method. -- ___ Python tracker ___ ___ Python-bugs-list

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: Dropping ABCMeta stops at instantiation. This should be in the dataclass code that's been generated. File "", line 2, in __init__ AttributeError: can't set attribute Repro: ``` class QuasiABC: @property @abstractmethod def x(self) -> int:

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: Have you tried dropping ABCMeta? Mypy checks @abstractmethod regardless. -- ___ Python tracker ___

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: We construct a computational graph and need to validate (or search for possible new) edges at runtime. The data is specific to computer vision. One example is clipping geometry within 2D boundaries. A minimal implementation of this data would be:

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: Thanks. Can you be specific about “modern libraries”? Please clarify your use cases. -- ___ Python tracker ___

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: Pardon my sloppiness. 1. That should have been PEP 544. The last point referred to the notion of data protocols [0]. 2. I think solving this issue for dataclasses would ensure better composition with modern libraries and other idioms like Protocol and

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Guido van Rossum added the comment: 1. PEP 554 is about multiple interpreters. Which PEP did you mean? 2. The double negative in “Wouldn't it pay off to not rewrite dataclass features” is confusing. What did you mean? -- nosy: +gvanrossum ___

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Alexander Hirner added the comment: Here, nothing but less boiler plate. Wouldn't it pay off to not rewrite dataclass features like frozen, replace, runtime refelection and the ability to use dataclass aware serialization libraries (e.g. pydantic)? I think @dataclass+@abstractproperty

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

Eric V. Smith added the comment: Is dataclasses doing something here that a regular, hand-written class wouldn't do? -- ___ Python tracker ___

[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

New submission from Alexander Hirner : 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

Re: data: protocol

On 08/05/2014 04:46, Steven D'Aprano wrote: On Wed, 07 May 2014 11:42:24 +0100, Robin Becker wrote: I have an outstanding request for ReportLab to allow images to be opened using the data: scheme. That used to be supported in python 2.7 using urllib, but in python 3.3 urllib2 -- urllib and at

Re: data: protocol

On Thu, May 8, 2014 at 4:34 AM, Robin Becker ro...@reportlab.com wrote: Since urllib doesn't always work as expected in 3.3 I've had to write a small stub for the special data: case. Doing all the splitting off of the headers seems harder than just doing the special case. However, there are a

Re: data: protocol

On 08/05/2014 16:07, Ian Kelly wrote: The DataHandler class in 3.4 is all of 14 lines of code. My first which makes me wonder why the old URLopener is still there and why all this wasn't done before 3.0 appeared. instinct would be to backport that and add it to some OpenerDirector

data: protocol

I have an outstanding request for ReportLab to allow images to be opened using the data: scheme. That used to be supported in python 2.7 using urllib, but in python 3.3 urllib2 -- urllib and at least the default urlopener doesn't support data: Is there a way to use the residual legacy of the

Re: data: protocol

On Wed, 07 May 2014 11:42:24 +0100, Robin Becker wrote: I have an outstanding request for ReportLab to allow images to be opened using the data: scheme. That used to be supported in python 2.7 using urllib, but in python 3.3 urllib2 -- urllib and at least the default urlopener doesn't support

Re: data: protocol

On Wed, May 7, 2014 at 4:42 AM, Robin Becker ro...@reportlab.com wrote: I have an outstanding request for ReportLab to allow images to be opened using the data: scheme. That used to be supported in python 2.7 using urllib, but in python 3.3 urllib2 -- urllib and at least the default urlopener