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
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