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

[Wes Turner]

Could these be things in types?

types.ClassType
types.InstanceType

types.DataClass
types.DataClassInstanceType (?)

I sent a PR with typo fixes and ``.. code:: python`` directives so that
syntax highlighting works (at least on GitHub).

https://github.com/python/peps/blob/master/pep-0557.rst

https://github.com/python/peps/pull/488

Additional notes:

- "DataClass" instead of "Data Class" would be easier to search for.
s/DataClass/Data Class/g?
- It's probably worth mentioning how hash works when frozen=True also here:
  https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
- The `hash` explanation could be a two column table for easier readability

What a great feature.

- Runtime data validation from annotations (like PyContracts,) would be cool
- __slots__ are worth the time

On Thursday, November 30, 2017, Antoine Pitrou <solipsis at 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 <guido at python.org <javascript:;>> wrote:
> >  On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer <carl at oddbird.net
> <javascript:;>> 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 at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> wes.turner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171130/72d0e311/attachment-0001.html>