I can't follow your specification. Maybe this is because the key phrase "dataclass type semantics" is left unspecified? You're showing an example using "@create_model" but there is nothing in the example telling me what effect that has on the class at runtime, and the type given for create_model() in the example just says that it takes a class and returns a function from T -> T. What role does this function play? I presume the @dataclass_transform() decorator returns a class decorator -- but how does the signature of create_model() enter into that class decorator's type? Also, do the three dots stand for a literal ellipsis (like in method stubs) or is there something I would have to type in there to make this work?
It might be helpful to show a more fully fleshed-out example, starting with complete code that does something simple but data-classy at runtime, and then showing how to use dataclass_transform() to make static checkers understand those semantics?
Let's decorate a cake instead,
On Fri, Apr 23, 2021 at 11:12 PM Eric Traut email@example.com wrote:
PEP 557 introduced the dataclass to the Python stdlib. Several popular libraries (including attrs, pydantic, and various libraries that support database ORMs such as django and edgedb) have behaviors that are similar to dataclass, but these behaviors cannot be described using standard type annotations.
To work around this limitation, mypy custom plugins have been developed for many of these libraries, but these plugins don't work with other type checkers, linters or language servers. They are also costly to maintain for library authors, and they require that Python developers know about the existence of these plugins and download and configure them within their environment.
I've been exploring ways to extend support for dataclass semantics to other other libraries in a standardized manner. I've posted a [proposal in the form of a proto-PEP]( https://github.com/microsoft/pyright/blob/master/specs/dataclass_transforms.... ).
The latest versions of pylance and pyright implement this proposal as a proof of concept. It was relatively easy to implement (on the order of a couple hundred lines of code), and I assume that it would be similarly easy for other type checkers to add this support.
I've created a [github discussion and feedback forum]( https://github.com/microsoft/pyright/discussions/1782), and I welcome feedback on the proposal. I've already been in contact with the maintainers of attrs and pydantic. They are generally supportive, and I've incorporated their initial input into the latest draft of the proposal.
-- Eric Traut Contributor to Pyright & Pylance Microsoft Corp. _______________________________________________ Typing-sig mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: firstname.lastname@example.org