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.
On Fri, Jan 5, 2018 at 11:06 AM, Eric V. Smith <e...@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 > > Which references: > 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 <e...@trueblade.com >> <mailto:e...@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 >> <e...@trueblade.com <mailto:e...@trueblade.com> >> <mailto:e...@trueblade.com <mailto:e...@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>> >> >> >> 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@python.org <mailto:Python-Dev@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/guido%40python.org >> <https://mail.python.org/mailman/options/python-dev/guido%40python.org> >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba- >> python-dev%40trueblade.com >> >> > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
