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

Antoine Pitrou solipsis at pitrou.net
Thu Nov 30 04:16:58 EST 2017


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 <guido at python.org> wrote:
>  On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer <carl at 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.
> 





More information about the Python-Dev mailing list