[Python-Dev] Concerns about method overriding and subclassing with dataclasses
Eric V. Smith
eric at trueblade.com
Fri Jan 5 14:11:03 EST 2018
On 1/5/2018 2:09 PM, Guido van Rossum wrote:
> I'm normally no big fan of things that take either a class or an
> instance, but since fields() does this, I think is_dataclass() should
> to. And that's the name I'd choose. OK on the pseudo-fields.
Sounds good. I'll open a bpo issue.
Eric.
> On Fri, Jan 5, 2018 at 11:06 AM, Eric V. Smith <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>
> On 1/5/2018 12:58 PM, Guido van Rossum wrote:
>
> Hm. I don't know that people will conclude that checking for a
> dataclass is an anti-pattern. They'll probably just invent a
> myriad of different hacks like the one you showed. I recommend
> making it public.
>
>
> I'm trying to track down the original discussion. We got bogged down
> on whether it worked for classes or instances or both, then we got
> tied up in naming it (surprise!), then it looks like we decided to
> just not include it since you could make those decisions for yourself.
>
> I think the discussion is buried in this thread:
> https://mail.python.org/pipermail/python-dev/2017-November/150966.html
> <https://mail.python.org/pipermail/python-dev/2017-November/150966.html>
>
> Which references:
> https://github.com/ericvsmith/dataclasses/issues/99
> <https://github.com/ericvsmith/dataclasses/issues/99>
>
> So, ignoring the naming issue, I think if we want to revive it, the
> question is: should isdataclass() return True on just instances,
> just classes, or both? And should it ever raise an exception, or
> just return False?
>
> I still worry a bit about ClassVar and InitVar being potentially
> useful but I concede I have no use case so I'll drop it.
>
>
> IIRC, we decided that we could add a parameter to
> dataclasses.fields() if we ever wanted to return pseudo-fields. But
> no one came up with a use case.
>
> Eric.
>
>
> On Fri, Jan 5, 2018 at 8:43 AM, Eric V. Smith
> <eric at trueblade.com <mailto:eric at trueblade.com>
> <mailto:eric at trueblade.com <mailto:eric at trueblade.com>>> wrote:
>
> On 1/5/2018 11:24 AM, Guido van Rossum wrote:
>
> On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith
> <eric at trueblade.com <mailto:eric at trueblade.com>
> <mailto:eric at trueblade.com <mailto:eric at trueblade.com>>
> <mailto:eric at trueblade.com <mailto:eric at trueblade.com>
> <mailto:eric at trueblade.com <mailto:eric at trueblade.com>>>> wrote:
>
> On 1/2/2018 12:01 AM, Guido van Rossum wrote:
>
> Yes, there's a class variable
> (__dataclass_fields__) that
> identifies the parent fields. The PEP doesn't
> mention
> this or
> the fact that special methods (like __repr__ and
> __init__) can
> tell whether a base class is a dataclass. It
> probably
> should
> though. (@Eric)
>
>
> I think that's covered in this section:
> https://www.python.org/dev/peps/pep-0557/#inheritance
> <https://www.python.org/dev/peps/pep-0557/#inheritance>
> <https://www.python.org/dev/peps/pep-0557/#inheritance
> <https://www.python.org/dev/peps/pep-0557/#inheritance>>
>
> <https://www.python.org/dev/peps/pep-0557/#inheritance
> <https://www.python.org/dev/peps/pep-0557/#inheritance>
> <https://www.python.org/dev/peps/pep-0557/#inheritance
> <https://www.python.org/dev/peps/pep-0557/#inheritance>>>
>
>
> I was specifically talking about the name and contents of
> __dataclass_fields__, which are not documented by the
> PEP. I
> expect it's inevitable that people will be looking at this
> (since they can see it in the source code). Or do you
> recommend
> that people use dataclasses.fields() and catch ValueError?
>
>
> The expectation is to use dataclasses.fields(). Both it and
> __dataclass_fields__ contain the fields for this class and the
> parents. The only difference is the pseudo-fields.
>
> I can add some words describing .fields() returning which
> fields are
> present.
>
> I notice that _isdataclass() exists but is private and
> I don't
> recall why.
>
>
> I think the argument was that it's an anti-pattern, and if you
> really want to know, just call dataclasses.fields() and
> catch the
> TypeError. I have this in a helper file:
>
> def isdataclass(obj):
> """Returns True for dataclass classes and instances."""
> try:
> dataclasses.fields(obj)
> return True
> except TypeError:
> return False
>
>
> (Also now I'm curious what
>
> the "pseudo-fields" are that fields() ignores, but
> that's OT.)
>
>
> ClassVar and InitVar "fields". dataclasses.fields() doesn't
> return them.
>
> Eric.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> <mailto:Python-Dev at python.org <mailto:Python-Dev at python.org>>
> https://mail.python.org/mailman/listinfo/python-dev
> <https://mail.python.org/mailman/listinfo/python-dev>
> <https://mail.python.org/mailman/listinfo/python-dev
> <https://mail.python.org/mailman/listinfo/python-dev>>
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
> <https://mail.python.org/mailman/options/python-dev/guido%40python.org>
> <https://mail.python.org/mailman/options/python-dev/guido%40python.org
> <https://mail.python.org/mailman/options/python-dev/guido%40python.org>>
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido
> <http://python.org/%7Eguido> <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org <mailto:Python-Dev at python.org>
> https://mail.python.org/mailman/listinfo/python-dev
> <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> <https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com>
>
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
More information about the Python-Dev
mailing list