I believe [`bpo-44806: Fix __init__ in subclasses of protocols`](https://github.com/python/cpython/pull/27545) has caused a regression when using a Dataclass. In Python `3.9.7`, a `dataclass` that inherits from a subclass of `typing.Protocol` (i.e., a user-defined protocol), does not have the correct `__init__`. ### Demonstration ```python from dataclasses import dataclass from typing import Protocol class P(Protocol): pass @dataclass class B(P): value: str print(B("test")) ``` In `3.9.7`: ```shell Traceback (most recent call last): File "test.py", line 11, in <module> print(B("test")) TypeError: B() takes no arguments ``` In `3.9.6`: ```shell B(value='test') ``` ### Affected Projects - [dbt](https://github.com/dbt-labs/dbt/issues/3843)

 New changeset 0635e201beaf52373f776ff32702795e38f43ae3 by Yurii Karabas in branch 'main': bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121) https://github.com/python/cpython/commit/0635e201beaf52373f776ff32702795e38f43ae3 

 New changeset 98eb40828af97760badfa7b8ff84bd4f7a079839 by Miss Islington (bot) in branch '3.9': bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121) (GH-28132) https://github.com/python/cpython/commit/98eb40828af97760badfa7b8ff84bd4f7a079839 

 New changeset 79e9f5a58427c73dc546cb571819d50defe2e14f by Miss Islington (bot) in branch '3.10': bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121) https://github.com/python/cpython/commit/79e9f5a58427c73dc546cb571819d50defe2e14f 

I believe this was a deeper issue that affected all classes inheriting Protocol, causing a TypeError on even the most basic case (see attached): Traceback (most recent call last): File "/.../test.py", line 14, in <module> MyClass() File "/.../test.py", line 11, in __init__ super().__init__() File "/usr/local/Cellar/python@3.9/3.9.7/Frameworks/Python.framework/Versions/3.9/lib/python3.9/typing.py", line 1083, in _no_init raise TypeError('Protocols cannot be instantiated') TypeError: Protocols cannot be instantiated This was a new regression in 3.9.7 and seems to be resolved by this fix. The desired behavior should be supported according to PEP 544: https://www.python.org/dev/peps/pep-0544/#explicitly-declaring-implementation

Ian, `MyProtocol` does not provide an `__init__()`, and thus ``` super().__init__() ``` is calling the `__init__()` from `Protocol`. This results in the `TypeError`. Simply remove `super().__init__()` to resolve your issue. This behavior was changed in https://github.com/python/cpython/pull/27545 (see `Lib/typing.py:1384`); I don't see what you are reporting as a regression, I see it as correct behavior that I would expect. Apologies if you feel differently. Cheers, Julian

Julian, That is certainly a workaround, however the behavior you are describing is inconsistent with PEP-544 in both word and intention. From the PEP: > To explicitly declare that a certain class implements a given protocol, it can be used as a regular base class. It further describes the semantics of inheriting as "unchanged" from a "regular base class". If the semantics are "unchanged" then it should follow that super().__init__() would pass through the protocol to the object.__init__, just like a "regular base class" would if it does not override __init__. Furthermore, the intention of inheriting a Protocol as described in the PEP: > Static analysis tools are expected to automatically detect that a class implements a given protocol. So while it's possible to subclass a protocol explicitly, it's not necessary to do so for the sake of type-checking. The purpose of adding a Protocol sub-class as an explicit base class is thus only to improve static analysis, it should *not* to modify the runtime semantics. Consider the case where a package maintainer wants to enhance the flexibility of their types by transitioning from using an ABC to using structural sub-typing. That simple typing change would be a breaking change to the package consumers, who must now remove a super().__init__() call. Ian