Support for libraries with dataclass semantics

[erictraut]

We've received feedback from pyright and pylance users that they would like to see better support for attrs, pydantic, django, edgedb, and other libraries that provide semantics similar to dataclass. Custom mypy plugins exist for all of these libraries, but these plugins are very specific to mypy and cannot be used in pyright or other Python type checkers or linters.

I've been working on a proposal that aims to provide support for this entire class of libraries in a standardized manner. If successful, this specification can be ratified as a PEP and adopted by the full suite of type checking and linting tools in the Python ecosystem.

I've posted a draft of this spec here, and I welcome feedback on it.

I've also implemented the code to support the current spec. It's included in pylance version 2021.4.2, which was released earlier today. It is also included in pyright 1.1.134. If you want to give it a try with either attrs or pydantic, please follow the instructions toward the end of the spec.

Note that this spec — and the corresponding implementation — are still in early forms and are subject to change.

[Tinche]

Hello,

I've applied the changes listed, updated Pylance and it seems to be working!

I am very happy about this. If I understand correctly, this behavior can be inherited by other wrappers in the same way, by applying __dataclass_transform__ in the same way? For example, the following is a model we use for serialization to the Flatbuffer format:

(from_package calls attr.define internally before generating methods for it), so I would just apply __dataclass_transform__ to the from_package function?

In any case, thanks a lot!

[erictraut]

Yes, this is meant to be a generalized mechanism that can be used by any library or code that implements dataclass-like semantics, so you could apply it to custom decorators like from_package in your example above.

[asford]

This would be a major step forward for our ability to adapt our code-based to use attrs or dataclasses based extension wrappers, allowing library authors to implement attrs' existing advice on wrapping the decorator in a type-compatible way!

[layday]

Thanks, this looks promising. I wonder if for Pydantic it would be more appropriate for constructor arguments to be of type Any, seeing as it functions as something of a data parser, e.g. for datatime it accepts both int (Unix time) and str (ISO), attempting to convert them into datetime objects.

[asford]

I have tried this out on an reasonably well-size internal codebase that's currently using attrs with the associated attrs mypy plugin, and have found it to work very well.

One pain-point for us would be the support for converter parameters to attrs fields. This is used extensively in our code base to provide type-adapting convertors for dataclass initialization. This is currently implemented in a very case-specific way by mypy's attrs plugin and is extremely useful.

For a pseudo-contrived example:

import attr
import enum
from typing import Union

class Foos(enum.Enum):
    foo = "foo"
    bar = "bar"


def parse_foos(value: Union[str, Foos]) -> Foos:
    return Foos(value)


@attr.define
class Data:
    a: Foos = attr.field(converter=parse_foos)

mypy types Data.__init__ as def (self: example.Data, a: Union[builtins.str, example.Foos])

Could you comment on the technical feasibility of expanding this spec to include support for converters on fields, perhaps with the following semantics?

• The converter parameter of a field descriptor must be a non-generic of the type Callable[[InputT], FieldT].
• The FieldT would be type-checked for assignment to the field's type annotation.
• The inferred type of the field's named parameter in the __init__ signature would be updated to InputT.

I can imagine that this could be reasonably complex, particularly if generics were supported in the Callable, however even non-generic support would go a long way toward "parity" between mypy and pyright support for these type of dataclass extensions.

I think this would explicitly not be an ask for the kinds of special-case support for the attrs-specific features in the existing mypy plugin, as upstream authors could adapt converter functions to expose Callable converters of the appropriate concrete types.

[erictraut]

Why not make the type conversion explicit for arguments when you call the constructor? In other words, why use cast(int, "27") when you could use int("27") instead? The latter is fewer characters, easier to read, and safer because cast effectively disables the type checker.

[samuelcolvin]

Because that's much more verbose, more open to errors and has a greater cognitive load.

To put it another way: if you're going to do it that way, there's no reason to use anything other than dataclasses.

Brief example:

class GoodKnight(BaseModel):
    title: str
    age: int
    card_number: CardNumber
    dob: date

    @validator('dob')
    def confirm_ancient(cls, d):
        assert d < date(1800, 1, 1)
        return d

# good knight usage elsewhere in the code base:
from models import GoodKnight

gk = GoodKnight(title='Sir Lancelot', age='23', card_number='4242 4242 4242 4242', dob='1680-04-20')

#######################################

@dataclass
class BadNight:
    title: str
    age: int
    card_number: CardNumberDataClass
    dob: date

# bad knight usage elsewhere in the code base:
from enforcers import enforce_str, enforce_int, encore_card_number, enforce_date, enforce_date_range
from models import BadKnight

bk = BadNight(
    title=enforce_str('Sir Lancelot'),
    age=enforc_int('23'),
    card_number=encore_card_number('4242 4242 4242 4242'),
    dob=enforce_date_range(enforce_date('1680-04-20')),
)

Now, imagine that model has 20 fields, and imagine using it in 50 different places across 15 modules, with varied inputs. Multiply that by 15 different models.

Which approach is easier?

[erictraut]

I guess it depends on how you define "easier" and what you're optimizing for. If your goal is to reduce the number of keystrokes when writing code, then the first example is preferable. If your goal is to write code that is as robust and maintainable as possible, then I'd say that the second example is preferable. I'll point out that the real comparison is not between the two examples above but between the second example and a variant of the first example that includes a bunch of cast calls.

I personally find the second example easier to understand because it's explicit, and it makes it clear what's happening. I appreciate that many Python developers would opt for the former though, especially when writing non-production code that does not need to be maintained over time. Python developers who appreciate the benefits of static type checking may be more aligned with my viewpoint.

[samuelcolvin]

I understand entirely where you're coming from.

But there are three problems with this:

1. There is no good equivalent of GoodKnight(**request_json_data) (or the technically more safe variant GoodKnight.parse_obj(request_json_data), which gives a proper validation error if the argument is not a dict) with the second approach.
2. The chance of making an error in the second approach is much higher than the first, even with perfect type checks
3. People do like the pydantic and attr approach of implementing validation/coercion logic in one place and wrapping it in a reusable object

[Tinche]

Can you elaborate on 1.?

[asford]

One minor gap is the current spec's ability to represent the attr.frozen API, which is equivalent to the standard attr.define decorator with a frozen=False default.

I believe this can be easily implemented in the current specification by providing an additional frozen_default parameter to the dataclass_transform and __dataclass_transform__ interface equivalent to the existing eq_default, order_default, et al.

[erictraut]

Yes, the spec could be extended to accommodate that. Or this could be one of those cases where you might need to adjust your code slightly (replace @attr.frozen with @attr.default(frozen=True)) for it to work with static type checking. The latter is consistent with @dataclass, so I would encourage the use of that form.

[asford]

Certainly possible, but the spec already defines the *_default parameters for eq, order, and kw_only.
The specific omission of this parameter would feel strange here, particularly when it's already in use in a major library?

[tiangolo]

This is awesome! 🤩🎉

Thanks for doing this @erictraut! I think this would improve a lot of use cases for many libraries (including new ones) that could adopt it.

I already made a PR to pydantic here: pydantic/pydantic#2721

---

As a side note, I know there are edge cases for each library, like converters, automatic data conversion, etc. But I think this would already be a huge improvement to the current state of things.

For example, I would like to have support for default in fields as a positional argument too (the first one) and not only as a keyword argument. But I see that standard dataclasses already impose that restriction, so I guess that would be cumbersome to support.

In any case, with all the corner cases I could imagine would appear for each specific library, this is already amazing, and a great improvement in the developer experience. 🚀

[patrick91]

Hi @erictraut, I wanted to send this a while ago! First of all thanks for doing this, it is a great addition! I've started working adding support for it to Strawberry a GraphQL library that is inspired by dataclasses.

I wanted to know if there's plans for decorating functions and make them modify the __init__ method of a class. For example in dataclasses you can do this:

@dataclass
class PyRight:
    is_awesome: bool = dataclasses.field(init=False, default=True)

and in strawberry we have something similar:

def get_is_awesome() -> bool:
    return True

@strawberry.type
class PyRight:
    is_awesome: bool = strawberry.field(resolver=get_is_awesome)

every time there's a resolver passed to strawberry.field we don't put that field in the __init__ method of the class.

Do think this will be supported in future?

The PR I'm working on is here: strawberry-graphql/strawberry#922

[erictraut]

Would it make sense to support an optional init parameter for the benefit of people who want to get the correct semantics with type checkers and language servers? I realize that the parameter would be redundant, but it still has value if it helps with the tooling. You could add code within the API to verify at runtime that it's not being set in a way that's inconsistent.

[patrick91]

@erictraut, yup! I think this is what we might end doing for the time being ^^

[patrick91]

@erictraut, I went for adding the init parameter, I was wondering, since we use overloads, couldn't we use literals to tell pyright that the field is not added to the constructor, ie, if I do this:

@overload
def field(
    *,
    resolver: Callable[[], T],
    init: Optional[Literal[False]] = False,
) -> T:
    ...

@overload
def field(
    *,
    resolver: Literal[None],
    init: Optional[Literal[False]] = False,
) -> Any:
    ...

passing a resolver means that init has to be False, and not passing it means that init has to be True?

[erictraut]

That's a really clever idea. I think that should be feasible to implement. I'll investigate further. If it works, I can also update the spec accordingly.

[patrick91]

Awesome, you're the best!

[jonasehrlich]

Hi @erictraut, thanks for bringing up this suggestion! Looks like a great addition.
Would it be feasible to support protocols as the return type for a decorator? Or even re-use the return annotation of the decorated function?

I think the decorator would be a nice way of "enforcing" metadata (in whatever form) to be attached to classes. In an ideal world, I would imagine something like the following:

class Model(Protocol[T]):
    __metadata__: Dict[str, Any]
    __message_type__: Type[T]

    def to_dict(self) -> Dict[str, Any]:
        ...

    def from_dict(cls: Type[T], data: Dict[str, Any]) -> T: 
        ...

    def to_message(self) -> T:
        ...

# The return type could be either explicitly defined in the __dataclass_transform__ decorator,
# or maybe directly inferred from the annotation of the decorated function
@__dataclass_transform__(return_type=Model[Message])
def model(message_type: Type[Message], **kwargs) -> Callable[[Type[Any]], Type[Model[Message]]]:
    def wrapper(cls: Type[Any]) -> Type[Model[Message]]:
        cls.__message_type__ = message_type
        cls.to_dict = obj_to_dict
        cls.from_dict = obj_from_dict
        cls = dataclass(cls)
        return cls
    return wrapper

# Some other module
@model(EmployeeMessage, metadata_key="value")
class Employee:
    id: int
    name: str

Employee(1, "John Doe").to_dict()
Employee.from_dict({"id": 2, "name": "Jane Doe"})

With the current implementation, the methods fail the type check using pylance. For a passing type check, all decorated classes need to inherit from the Model protocol as well, which makes the whole API harder to use.

Or would the better solution for be, to completely ditch the decorator approach, move the metadata to a class attribute (or a nested Meta class, similar to how Django does it) and move the checking of this "enforced" metadata to a Metaclass?
While typing-wise the implementation would probably be easier, the implementation is imho way less explicit than a decorator with required arguments.

[erictraut]

What you're doing here is pretty far afield of a dataclass transform. You're effectively applying a completely separate transform to an existing class. And you're doing so in a way that's pretty hacky, IMO, because you're not simply transforming one class into another, you're mutating the original class by injecting attributes into it. If I were to call FooModel = model(Foo), I would be pretty surprised to find that the call modified the class Foo!

I don't think it makes sense to encumber dataclass_transform with this other form of class transform. We may want to introduce other types of descriptive class transforms in the future, but that should be separate from dataclass_transform.

For your use case, you might want to explore the use of a metaclass. Here's how that would look:

@__dataclass_transform__()
class ModelMeta(type):
    ...

class Model(Generic[T], metaclass=ModelMeta):
    @property
    def __metadata__(self) -> Dict[str, Any]:
        ...

    @property
    def __message_type__(self) -> Type[T]:
        ...

    def to_dict(self) -> Dict[str, Any]:
        ...

    @staticmethod
    def from_dict(data: Dict[str, Any]) -> T:
        ...

    def to_message(self) -> T:
        ...

class Message: ...
class EmployeeMessage(Message): ...

class Employee(Model[EmployeeMessage]):
    id: int
    name: str

Employee(1, "John Doe").to_dict()
Employee.from_dict({"id": 2, "name": "Jane Doe"})

[jonasehrlich]

Thank you for your suggestion! I guess it is a pretty far shot to do runtime modifications of classes in decorators.

Actually the decorator was initially only used to register the model and the message, in a registry to be able to map them to each other afterwards. But somehow having the conversion methods available directly on the instances / classes was too handy, so I just added it to the decorator without re-thinking the approach.

I moved the implementation to use a metaclass. Additionally, the __metadata__ attribute is now defined as a ClassVar to make the type checker happy (and to avoid that a field is created from it).

[rslinckx]

Would this proposal also work with ORM-style classes, such as sqlalchemy ?

One thing I could see as problematic is that in sqlalchemy each field has a different behavior whether it's called as an object instance or a class field, for example

from sqlalchemy.orm import registry
mapper_registry = registry()

@mapper_registry.mapped
class Foo:
  __table__ = Table('foo', mapper_registry.metadata, Column('a', Integer))
  a: Optional[Mapped[int]]

In this case: Foo.a -> Column while Foo().a -> int

Otherwise I think the Foo is more or less a pseudo-declarative class, in that it synthetizes an init(self, a: Optional[int]=None) method. However I'm not an expert in the subtleties of sqlalchemy to see if it would break down in some edge cases...

There's a related discussion here: sqlalchemy/sqlalchemy2-stubs#170

[erictraut]

I'm not an expert on sqlalchemy either, but I have spent some time looking at the mypy plugin for sqlalchemy. That library has various dynamic behaviors that do not match the behavior of dataclass. This proposal wouldn't cover those non-standard behaviors.

[tiangolo]

Just FYI, I released SQLModel a couple of weeks ago, mixing SQLAlchemy and Pydantic. And optimizing editor support (autocompletion and inline errors).

One of the main things I wanted to achieve (and one of the main features of SQLModel) is that it's all built using dataclass_transforms (and other tricks) to get all those nice editor features. ✨

[layday]

SQLModel is great if you are a Pydantic user, but not everybody is, and not everybody would want to add another layer of abstraction on top of SQLAlchemy and its ORM. To type an ORM class, currently, so that it works with Pyright, you have to define the table, annotate the attributes, keeping them in sync with table's cols, and write your own (typing-only) constructor, where all arguments are optional. This all ends up looking something like this, sans relationships:

@mapper_registry.mapped
class Foo:
    __table__ = Table(
        'foo',
        mapper_registry.metadata,
        Column('a', String, primary_key=True),
        Column('b', TZDateTime, nullable=False, server_default=func.now()),
        Column('c', String, primary_key=True),
        Column('d', String, primary_key=True),
    )

    a: Mapped[str]
    b: Mapped[datetime]
    c: Mapped[str]
    d: Mapped[str]

    if TYPE_CHECKING:

        def __init__(
            self,
            *,
            a: str = ...,
            b: datetime = ...,
            c: str = ...,
            d: str = ...,
        ) -> None:
            ...

Unsightly and error-prone, and it makes me wonder what the future of ORMs is. That is, if change should be sought from the typing side of things, or from the ORMs themselves.

[adsharma]

Looks like you're talking about "dataclasses with imperative table" here. There is also a second way: "dataclasses with declarative table". Are there significant issues in supporting them with pyright? https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#example-two-dataclasses-with-declarative-table

…

On Tue, Sep 7, 2021 at 6:11 AM layday ***@***.***> wrote: SQLModel is great if you are a Pydantic user, but not everybody is, and not everybody would want to add another layer of abstraction on top of SQLAlchemy and its ORM. To type an ORM class, currently, so that it works with Pyright, you have to define the table, annotate the attributes keeping them in sync with table's cols, *and* write your own (typing-only) constructor, where all arguments are optional. This all ends up looking something like this, sans relationships: @mapper_registry.mappedclass Foo: __table__ = Table( 'foo', mapper_registry.metadata, Column('a', String, primary_key=True), Column('b', TZDateTime, nullable=False, server_default=func.now()), Column('c', String, primary_key=True), Column('d', String, primary_key=True), ) a: Mapped[str] b: Mapped[datetime] c: Mapped[str] d: Mapped[str] if TYPE_CHECKING: def __init__( self, *, a: str = ..., b: datetime = ..., c: str = ..., d: str = ..., ) -> None: ... Unsightly and error-prone, and it makes me wonder what the future of ORMs is. That is, if change should be sought from the typing side of things, or from the ORMs themselves. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1782 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFA2A6S3QMZQUYPUCTTXP3UAYFQFANCNFSM43LQXPBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[layday]

You'd still need a way to express that the types of the attributes is different on the class without interfering with the dataclass transform.

[SandyChapman]

I've created a decorator that wraps pydantic's dataclass decorator using this proposal. This allows you to have static and run-time typecheckable dataclasses without modifying pydantic directly.

https://gist.github.com/SandyChapman/ffd40a2e46754f1341a0135ab2cb7202

[d-miketa]

I have a related issue with Pyright 1.1.195 and Python 3.8. I defined a decorator, @argclass(func), which imbues the decorated class with attributes corresponding to each of func's arguments. Example:

from dataclasses import dataclass
from argclass import argclass


def talk_about_apples(name: str, num_apples: int = 3):
    print(f"My name is {name} and I have {num_apples} apples.")


@argclass(talk_about_apples)
class TalkArgs:
    pass


# for comparison, this is the explicit version
@dataclass
class DataTalkArgs:
    name: str
    num_apples: int = 3


arg_keith = TalkArgs(name="Keith")  # this works
arg_wysa = TalkArgs()  # this would fail ('name' is missing)
data_keith = DataTalkArgs()  # this would also fail ('name' is missing)

This all works well (including default values), but neither signature nor hover doc are showing up – even though TalkArgs.__doc__ exists and inspect.signature(TalkArgs) is as it should be. My __init__.pyi looks like this:

from typing import Any, Callable, Tuple, TypeVar, Union

_T = TypeVar("_T")


def __dataclass_transform__(
    *,
    eq_default: bool = True,
    order_default: bool = False,
    kw_only_default: bool = False,
    field_descriptors: Tuple[Union[type, Callable[..., Any]], ...] = (()),
) -> Callable[[_T], _T]:
    ...


@__dataclass_transform__()
def argclass(func) -> Callable[[type], type]:
    ...

My best guess is that Pyright doesn't know that TalkArgs will synthesise its own doc and __init__() by constructing a dataclass. But from what I understand that's exactly what this proposal should be fixing. I'd be grateful for any hints towards a fix!

[erictraut]

Your assumption is correct. Yeah, your use case is quite different from that of a dataclass, so this proposal won't work for you.

[d-miketa]

Understood; I'll put the idea to rest for now then. Thanks again for your patience and your work on Pyright!

[d-miketa]

Apologies, this is the final hail Mary! Is there a chance you'd be open to extending the spec to dynamically generated dataclasses? Seems to me it's doable:

Stdlib dataclasses (make_dataclass) (Link)
data_cls = make_dataclass(name, fields = ...) can look at fields directly.

Stdlib dataclasses (dynamically applied decorator) (Link)
data_cls = dataclass(cls) can look at cls.__annotations__ to determine dataclass attributes – but cls.__annotations__ has to be dynamically set through setattr(cls, '__annotations__', annotations) and I'm not sure you support that. At any rate there's the above option which works just as well as a fallback!

Pydantic (Link)
DynamicFoobarModel = create_model('DynamicFoobarModel', foo=(str, ...), bar=123) can look at the kwargs.

attrs (Link)
data_cls = make_class(name, attrs, ...) can look at the second argument directly.

It's a bit heterogeneous but looks like a finite amount of effort, and having dynamically generated but correctly parsed dataclasses (& family) could be helpful in more scenarios than just the one I'm concerned with (automatic generation of Config classes for, say, PyTorch modules).

[erictraut]

These dynamic forms are typically used in cases where types are also dynamic and cannot be analyzed by a static type checker, so they are not supported in any form today by any of the static type checkers. If the field types are known statically, then you should use the standard (non-dynamic) class definition form.

So no, I don't think it makes sense to add this additional complexity to the spec. We are pushing to get this spec adopted as a PEP, and adding unnecessary complexities to it will reduce its chances of being accepted.

[d-miketa]

I see – sounds like sensible priorities. Good luck with PEP!

[ITProKyle]

Regarding alias from the current revision of the spec:

alias is an optional str parameter that provides an alternative name for the field. This alternative name is used in the synthesized init method.

Would is be possible to support the use of either the defined field name or the alias?

pydantic uses a config option of allow_population_by_field_name to allow the model fields to be populated by either the alias or the defined field name. pyright could identify allow_population_by_field_name=True as a class option to enable this as it does currently for options like frozen. From an implementation standpoint for type checkers, it probably would not be feasible to support a mix of alias and field names but overloading the synthesized __init__ method for using all aliases or all field names would be a usable middle ground.

For my use case I would like to define, consume, and (optionally) populate the fields using snake case (standardized across the library) but when I convert the model object into a dict (using pydantic.BaseModel.dict()) to send the data to an external service it needs to be pascal case. Sure, I could override the .dict() method of the base class or do further conversion of data after it's converted to a dict but that detracts from the advantages of using a library like pydantic.

from pydantic import BaseModel, Field


class ExampleModel(BaseModel, allow_population_by_field_name=True):
    field_one: str = Field(..., alias="FieldOne")
    field_two: str = Field(..., alias="FieldTwo")


# pass type check
assert ExampleModel(field_one="foo", field_two="bar").dict(by_alias=True) == {
    "FieldOne": "foo",
    "FieldTwo": "bar",
}
assert ExampleModel(FieldOne="foo", FieldTwo="bar").dict(by_alias=True) == {
    "FieldOne": "foo",
    "FieldTwo": "bar",
}

# fail type check
assert ExampleModel(FieldOne="foo", field_two="bar").dict(by_alias=True) == {
    "FieldOne": "foo",
    "FieldTwo": "bar",
}

[erictraut]

No, I don't think it would be consistent with the principles we used when creating this spec. The feature that you're talking about here is very specific to pydantic and doesn't apply to any other libraries. I'm already uncomfortable supporting the "alias" field as it's currently defined in the spec because it's one of the few extensions that are not part of the stdlib dataclass spec.

[tmke8]

I see that the current implementation in pyright also automatically respects InitVar and checks __post_init__() when the dataclass transform decorator is used:

from dataclasses import InitVar, dataclass
from typing import Any, Callable, Tuple, Type, TypeVar, Union

_T = TypeVar("_T")

def __dataclass_transform__(
    *,
    eq_default: bool = True,
    order_default: bool = False,
    kw_only_default: bool = False,
    field_descriptors: Tuple[Union[type, Callable[..., Any]], ...] = (()),
) -> Callable[[_T], _T]:
    return lambda a: a

@__dataclass_transform__()
def dtc() -> Callable[[Type[_T]], Type[_T]]:
    return dataclass()

@dtc()
class CustomerModel:
    id: InitVar[int]
    name: str

    def __post_init__(self) -> None:  # pyright (in this case rightly) complains
        # self.name = self.name + str(id)
        pass

if __name__ == "__main__":
    c = CustomerModel(3, "hi")  # fails at runtime because post_init is wrong
    print(c)

In this case, this check happens to be correct, but in other cases it probably isn't, right? For example, it seems attrs just ignores the InitVar annotation:

@attr.define
class A:
    b: InitVar[int]
    c: str

a = A(b=3, c="foo")
print(a.b)

gives 3.

[erictraut]

Yeah, I don't think the current versions of attrs honors InitVar, so you shouldn't use the two together.

[multimeric]

How does pyright determine if a decorator should work like typing.dataclass_transform? e.g. why does pydantic.main.__dataclass_transform__ work with pyright? I can't find this behaviour in the PEP.
https://github.com/samuelcolvin/pydantic/blob/abea8232eef0eeeb728824cdec9b445dfbd3192e/pydantic/main.py#L97-L104

[erictraut]

See here for details.

[erictraut]

Note that __dataclass_transform__ (the dundered version) is not part of the spec and will not work with other type checkers. Pydantic and other libraries should switch to typing.dataclass_transform now that PEP 681 has been accepted.

[multimeric]

Thanks for the info. I've opened an "issue" in pydantic here.

[felixvd]

I see that the dataclass_transforms spec has been removed. Has this feature been dropped?

Linking #607 since I came here trying to determine how extensible Pyright is.

[JelleZijlstra]

dataclass_transform is now a standard Python feature (see PEP 681), which is I assume why the spec was removed from this repo.

[felixvd]

True. Thanks for the clarification.