> > * ``hash`` is an alias for the ``unsafe_hash`` parameter.

> 

> Reasoning for providing this alias? Seems inconsistent.

 

@Eric Traut, I assume this was added because attrs uses "hash" instead of "unsafe_hash". However, the attrs hashing documentation [1] strongly discourages users from setting hash to True. I assume that means that it is infrequently used. Perhaps we should remove this alias and if attrs feels that this is important they should add an unsafe_hash alias on their side?

 

> Alternate form

 

Thanks for pointing this out. I just removed this section from the PEP. [2] Pyright's support of the alternate form was added so libraries could experiment with dataclass_transform before the official decorator was available, even before the PEP was written. Now that the decorator is in typing_extensions the alternate form should not be mentioned in the PEP.

 

> @dataclass_tranform *could* be used on Django's models.Model base class.

 

This is great news! I've been trying to find a Django contributor who might be interested in experimenting with dataclass_transform and providing feedback. If you know a good contact, please let me know.

 

> Is there potential openness to adding support for declaring that a particular dataclass_transform does autogenerate

> certain "extra fields" with known names and types (like "id: int")? Either in this PEP or in a future PEP?

 

In future PEPs, yes. Pradeep suggested an add_attributes decorator during a discussion back in November [3]. Since this would be useful outside of dataclasses, I think it would be better to spec it separately from dataclass_transform.

 

Thanks for your feedback David!

 

-Erik

 

[1] https://www.attrs.org/en/stable/hashing.html

[2] https://github.com/python/peps/pull/2386

[3] https://mail.python.org/archives/list/typing-sig@python.org/message/I2XJ6TTZGTUFDFUEDP3OSZ542O5U4DXW/

 

-----Original Message-----
From: David Foster <davidfstr@gmail.com>
Sent: Saturday, March 5, 2022 7:09 AM
To: Erik De Bonte <Erik.DeBonte@microsoft.com>; typing-sig@python.org
Subject: Re: [Typing-sig] Re: Dataclass Transform draft PEP

 

[You don't often get email from davidfstr@gmail.com. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]

 

Hi Erik, the dataclass_transform PEP looks great!

 

I left some (mostly-stylistic) feedback in:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fpeps%2Fpull%2F2382&amp;data=04%7C01%7CErik.DeBonte%40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=qzBipr%2Bao3GNiUXcVMHdUhxBfPAUe%2Fi5iEwJYkeQHcg%3D&amp;reserved=0

 

And here's additional feedback...

 

> * ``hash`` is an alias for the ``unsafe_hash`` parameter.

 

Reasoning for providing this alias? Seems inconsistent. And perhaps unsafe to do if potentially disguising an unsafe feature as (by-default) safe.

 

> Alternate form

> --------------

>

> To avoid delaying adoption of this proposal until after  > ``dataclass_transform`` has been added to the ``typing`` module, type  > checkers may support the alternative form ``__dataclass_transform__``.

 

(1) Could you provide an example of how this alternate form is actually used to mark a function, class, or metaclass?

 

Perhaps the example could be extended with something like:

 

```

@__dataclass_transform__(kw_only_default=True, order_default=True) def create_model(

     *,

     frozen: bool = False,

     kw_only: bool = True,

     ) -> Callable[[Type[_T]], Type[_T]]: ...

```

 

(2) Is the above syntax accepted in a .pyi stub file by popular typecheckers that already exist? If I was a typechecker I *might* find it sketchy to see use of a stub decorator declared in the same file.

 

> Rejected Ideas

> ==============

 

> Django primary and foreign keys

> -------------------------------

 

> users of Django would need to explicitly declare the ``id`` field.

 

As a Django user this is a bit inconvenient, but seems fine.

(No changes suggested.)

 

> This limitation may make it impractical to use the  > ``dataclass_transform`` mechanism with Django.

 

I wonder if this is too strong a statement... Everything I've read so far, minus the inconvenience of not autogenerating an "id" field, suggests that @dataclass_tranform *could* be used on Django's models.Model base class.

 

Is there potential openness to adding support for declaring that a particular dataclass_transform does autogenerate certain "extra fields"

with known names and types (like "id: int")? Either in this PEP or in a future PEP?

 

Cheers,

--

David Foster | Seattle, WA, USA

Contributor to TypedDict, mypy, and Python's typing system

 

On 3/4/22 3:42 PM, Erik De Bonte via Typing-sig wrote:

> Reminder to provide feedback on the dataclass_transform PEP [1] if you

> have any.

> 

> In particular, if you maintain a type checker and have any concerns,

> please let me know.

> 

> Thanks,

> 

> Erik

> 

> [1]

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.

> python.org%2Fdev%2Fpeps%2Fpep-0681%2F&amp;data=04%7C01%7CErik.DeBonte%

> 40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553%7C72f988bf86f141af9

> 1ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnknown%7CTWFpbGZsb3d8e

> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30

> 00&amp;sdata=y8o1w62SOJcUp%2Bs7DGquJFxeD2jFes%2BMadgVUdU1BK0%3D&amp;re

> served=0

> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww

> .python.org%2Fdev%2Fpeps%2Fpep-0681%2F&amp;data=04%7C01%7CErik.DeBonte

> %40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553%7C72f988bf86f141af

> 91ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnknown%7CTWFpbGZsb3d8

> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3

> 000&amp;sdata=y8o1w62SOJcUp%2Bs7DGquJFxeD2jFes%2BMadgVUdU1BK0%3D&amp;r

> eserved=0>

> 

> *From:* Erik De Bonte

> *Sent:* Monday, December 13, 2021 1:37 PM

> *To:* 'typing-sig@python.org' <typing-sig@python.org>

> *Subject:* Dataclass Transform draft PEP

> 

> I’ve created a draft PEP for the “Dataclass Transforms” concept that

> Eric Traut presented at the December 1^st Typing SIG meetup. Feedback

> is welcome!

> 

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith

> ub.com%2Fdebonte%2Fpeps%2Fblob%2Fdataclass_transforms%2Fpep-9999.rst&a

> mp;data=04%7C01%7CErik.DeBonte%40microsoft.com%7C018f5884d1fd42b8cc360

> 8d9feba2553%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6378208977181

> 43705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB

> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=B4rYfZbwlEhXWkhCjXKfoEzf98

> 5cwSg1Sz%2Bp%2BRddNZA%3D&amp;reserved=0

> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit

> hub.com%2Fdebonte%2Fpeps%2Fblob%2Fdataclass_transforms%2Fpep-9999.rst&

> amp;data=04%7C01%7CErik.DeBonte%40microsoft.com%7C018f5884d1fd42b8cc36

> 08d9feba2553%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820897718

> 143705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ

> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=B4rYfZbwlEhXWkhCjXKfoEzf9

> 85cwSg1Sz%2Bp%2BRddNZA%3D&amp;reserved=0>

> 

> Thanks,

> 

> Erik

> 

> 

> _______________________________________________

> Typing-sig mailing list -- typing-sig@python.org To unsubscribe send

> an email to typing-sig-leave@python.org

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail

> .python.org%2Fmailman3%2Flists%2Ftyping-sig.python.org%2F&amp;data=04%

> 7C01%7CErik.DeBonte%40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553

> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnk

> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw

> iLCJXVCI6Mn0%3D%7C3000&amp;sdata=oWXw220vLouj6mqsEU8ty%2F5LpXXd8HtxlSE

> qGT7pJ%2FI%3D&amp;reserved=0

> Member address: davidfstr@gmail.com