On Fri, Jan 5, 2018 at 11:06 AM, Eric V. Smith <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 1/5/2018 11:24 AM, Guido van Rossum wrote:
On Fri, Jan 5, 2018 at 5:08 AM, Eric V. Smith
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
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>)