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