Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

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 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...