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?
> On Thu, 30 Nov 2017 10:16:58 +0100
> Antoine Pitrou <firstname.lastname@example.org> wrote:
>> isdataclass() testing for instance-ship does sound like a bug magnet to
>> If isdataclassinstance() is too long (that's understandable), how about
>> On Wed, 29 Nov 2017 17:02:21 -0800
>> Guido van Rossum <email@example.com> wrote:
>>> On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer <firstname.lastname@example.org> wrote:
>>>> On 11/29/2017 03:26 PM, Eric V. Smith wrote:
>>>>> I've posted a new version of PEP 557, it should soon be available at
>>>>> The only significant changes since the last version are:
>>>>> - changing the "compare" parameter to be "order", since that more
>>>>> accurately reflects what it does.
>>>>> - Having the combination of "eq=False" and "order=True" raise an
>>>>> exception instead of silently changing eq to True.
>>>>> There were no other issues raised with the previous version of the PEP.
>>>> Not quite; I also raised the issue of isdataclass(ADataClass) returning
>>>> False. I still think that's likely to be a cause of bug reports if left
>>> I tried to look up the discussion but didn't find much except that you
>>> flagged this as an issue. To repeat, your concern is that isdataclass()
>>> applies to *instances*, not classes, which is how Eric has designed it, but
>>> you worry that either through the name or just because people don't read
>>> the docs it will be confusing. What do you suppose we do? I think making it
>>> work for classes as well as for instances would cause another category of
>>> bugs (confusion between cases where a class is needed vs. an instance
>>> abound in other situations -- we don't want to add to that). Maybe it
>>> should raise TypeError when passed a class (unless its metaclass is a
>>> dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a
>>> mouthful, but I don't know how common the need to call this is, and people
>>> who call it a lot can define their own shorter alias.
> Python-Dev mailing list
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
Python-Dev mailing list