On Thu, 30 Nov 2017 at 05:00 Eric V. Smith <e...@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? -Brett > > Eric. > > > > > On Thu, 30 Nov 2017 10:16:58 +0100 > > Antoine Pitrou <solip...@pitrou.net> wrote: > >> isdataclass() testing for instance-ship does sound like a bug magnet to > >> me. > >> > >> If isdataclassinstance() is too long (that's understandable), how about > >> isdatainstance()? > >> > >> Regards > >> > >> Antoine. > >> > >> > >> On Wed, 29 Nov 2017 17:02:21 -0800 > >> Guido van Rossum <gu...@python.org> wrote: > >>> On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer <c...@oddbird.net> > 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 > >>>>> https://www.python.org/dev/peps/pep-0557/. > >>>>> > >>>>> 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 > >>>> as-is. > >>>> > >>> > >>> 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 > > 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 > > > > _______________________________________________ > 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/brett%40python.org >
_______________________________________________ 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
