
Does the PEP/implementation take into account the return type specified in the functions signature? For example, assuming we had Intersection as a type, would this work? class HasSomeAttr(typing.Protocol): attr: str @typing.dataclass_transform( kw_only_default=True, field_descriptors=(model_field, )) def create_model( *, init: bool = True, ) -> Callable[[Type[_T]], typing.Intersection[Type[_T], HasSomeAttr]]: ... On Sat, 5 Mar 2022 at 09:10, David Foster <davidfstr@gmail.com> wrote:
Hi Erik, the dataclass_transform PEP looks great!
I left some (mostly-stylistic) feedback in: https://github.com/python/peps/pull/2382
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://www.python.org/dev/peps/pep-0681/ <https://www.python.org/dev/peps/pep-0681/>
*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://github.com/debonte/peps/blob/dataclass_transforms/pep-9999.rst <https://github.com/debonte/peps/blob/dataclass_transforms/pep-9999.rst>
Thanks,
Erik
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: davidfstr@gmail.com
Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: patrick.arminio@gmail.com
-- Patrick Arminio