On 11/30/2017 7:22 PM, Eric V. Smith wrote:
On 11/30/2017 1:30 PM, Brett Cannon wrote:
On Thu, 30 Nov 2017 at 05:00 Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but far more > readable thanks to explicit word boundaries :-)
That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely: what actually happens will no doubt surprise me.
So I'm okay with is_dataclass_instance() and is_dataclass_class().
But then I'm also okay with dropping the API entirely. nametuple has lived for years without it, although Raymond's advice there is that if you really want to know, look for _fields. See https://bugs.python.org/issue7796#msg99869 and the following discussion.
My question was going to be whether this is even necessary. :) Perhaps we just drop it for now and add it in if we find there's a public need for it?
That's what I'm leaning toward. I've been trying to figure out what attr.has() or hasattr(obj, '_fields') are actually used for. The attrs version is hard to search for, and while I see the question about namedtuples asked fairly often on SO, I haven't seen an actual use case.
It's easy enough for someone to write their own isdataclass(), admittedly using an undocumented feature.
Actually there's a supported way to write your own isdataclass(): call dataclasses.fields(obj). If it throws a TypeError, it's not a dataclass instance or class. I'll add a note to the PEP.
Eric.
So I'm thinking let's drop it and then gauge the demand for it, if any.
Eric.
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%40tru...