I'd be happy to present the proposal in the next Typing Meetup if there are available slots.

I'm interested in opinions from the broader typing community. Is there enough interest to justify a formal PEP and moving it through the standards

I've been thinking about ways that these types of "class transforms" could be described in a declarative manner for static type checkers. I'm

Yeah, I'm happy to have you present this at the next typing meetup, the week after next. (I'd reached out last time about this but we couldn't make it happen.) process? I welcome such standardized patterns that eliminate the need for ad hoc plugins. Pyre right now has ad hoc support for both `dataclass` and `sqlalchemy` declarative classes, so it would be good to generalize them. The current `dataclass_transform` approach, though, is rather opaque and not very extensible. Given how many other frameworks need something similar but with variations, I think it's worth getting this right in general. Otherwise, we'd need a new transform for django ORM, sqlalchemy ORM, etc. I think we should go for a declarative, protocol-based specification of the transform. You'd alluded to something like this in [1]: thinking that it would be in a similar vein to the `typing.dataclass_transform` mechanism that I proposed in [this spec]( https://github.com/microsoft/pyright/blob/main/specs/dataclass_transforms.md). This hypothetical `typing.class_transform` decorator would take a protocol class as an argument, and the type checker would then "merge" the protocol attributes and methods into the decorated class, creating a new transformed class in the process. This would properly model what the wrapping class does in this case. That would allow us to add attributes and methods to a class in an explicit, flexible manner. For example, `sqlalchemy` needs to add attributes like `__tablename__` and `metadata`. ``` # library.py import sqlalchemy from typing import Protocol class SqlalchemyMethods(Protocol): table: sqlalchemy.Table metadata: sqlalchemy.MetaData __tablename__: str def __eq__(self, other: object) -> bool: ... # Any class with metaclass `SqlalchemyMeta` will have the above attributes. @add_attributes(SqlalchemyMethods) class SqlalchemyMeta(type): ... class Base(metaclass=SqlalchemyMeta): ... # customer.py class CustomerModel(Base): id: int name: str customer: CustomerModel customer.id # => int customer.name # => str customer.table # => sqlalchemy.Table customer.__tablename__ # => str customer.__eq__ # => (object) -> bool ``` Adding attributes and methods is relatively straightforward. The main challenge is in handling special methods like `__init__` (for a dataclass or sqlalchemy class or django ORM class), because the signature will vary based on the other attributes of the class. If we can find a way to represent that cleanly, we can use a single transform like `@add_attributes` to represent all of these various frameworks (and any new ones in the future). Can't spend too much time on this thread this week, but happy to hash out some details before the meetup. This should be a lively discussion :) [1]: https://mail.python.org/archives/list/typing-sig@python.org/message/TUDTEIQI.... He also discussed why pure intersection types won't help much here. [2]: Eric's original thread: https://mail.python.org/archives/list/typing-sig@python.org/thread/TXL5LEHYX... On Thu, Nov 18, 2021 at 8:31 PM Eric Traut <eric@traut.com> wrote:

A while back, I posted a draft proposal for a new typing construct called `dataclass_transform`. Here's a link to the full spec: https://github.com/microsoft/pyright/blob/main/specs/dataclass_transforms.md

I released a reference implementation in pyright. A couple of popular libraries (`attrs` and `pydantic`) have provisionally adopted it. Several other use cases for it have also been proposed, including support for dataclass decorator aliases, discussed in this mypy issue thread: https://github.com/python/mypy/issues/5383.

I'm interested in opinions from the broader typing community. Is there enough interest to justify a formal PEP and moving it through the standards process?

I'd be happy to present the proposal in the next Typing Meetup if there are available slots.

--

Eric Traut Contributor to Pyright & Pylance Microsoft _______________________________________________ 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: gohanpra@gmail.com

-- S Pradeep Kumar