
* ``hash`` is an alias for the ``unsafe_hash`` parameter.
Reasoning for providing this alias? Seems inconsistent.
@Eric Traut<mailto:erictr@microsoft.com>, 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/I2XJ6TTZ... -----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<mailto: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... 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&data=04%7C01%7CErik.DeBonte%
40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553%7C72f988bf86f141af9
1ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnknown%7CTWFpbGZsb3d8e
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
00&sdata=y8o1w62SOJcUp%2Bs7DGquJFxeD2jFes%2BMadgVUdU1BK0%3D&re
served=0
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.python.org%2Fdev%2Fpeps%2Fpep-0681%2F&data=04%7C01%7CErik.DeBonte
%40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553%7C72f988bf86f141af
91ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000&sdata=y8o1w62SOJcUp%2Bs7DGquJFxeD2jFes%2BMadgVUdU1BK0%3D&r
eserved=0>
*From:* Erik De Bonte
*Sent:* Monday, December 13, 2021 1:37 PM
*To:* 'typing-sig@python.org' <typing-sig@python.org<mailto: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&sdata=B4rYfZbwlEhXWkhCjXKfoEzf98
5cwSg1Sz%2Bp%2BRddNZA%3D&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&sdata=B4rYfZbwlEhXWkhCjXKfoEzf9
85cwSg1Sz%2Bp%2BRddNZA%3D&reserved=0>
Thanks,
Erik
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org<mailto:typing-sig@python.org> To unsubscribe send
an email to typing-sig-leave@python.org<mailto: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&data=04%
7C01%7CErik.DeBonte%40microsoft.com%7C018f5884d1fd42b8cc3608d9feba2553
%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637820897718143705%7CUnk
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
iLCJXVCI6Mn0%3D%7C3000&sdata=oWXw220vLouj6mqsEU8ty%2F5LpXXd8HtxlSE
qGT7pJ%2FI%3D&reserved=0
Member address: davidfstr@gmail.com<mailto:davidfstr@gmail.com>