[Python-Dev] Third and hopefully final post: PEP 557, Data Classes
Eric V. Smith
eric at trueblade.com
Fri Dec 1 02:49:35 EST 2017
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 at trueblade.com
>> <mailto:eric at 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
>> if ever. Or more realistically, it should be used rarely: what
>> 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
>> 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.
> So I'm thinking let's drop it and then gauge the demand for it, if any.
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev