> I'd be happy to present the proposal in the next Typing Meetup if there are available slots.
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.)
> 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 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]:
> 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 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).