I believe bpo-44806: Fix __init__ in subclasses of protocols 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

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:

Traceback (most recent call last):
  File "test.py", line 11, in <module>
    print(B("test"))
TypeError: B() takes no arguments

In 3.9.6:

B(value='test')

### Affected Projects

• dbt

New changeset 0635e20 by Yurii Karabas in branch 'main':
bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121)
0635e20

New changeset 98eb408 by Miss Islington (bot) in branch '3.9':
bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121) (GH-28132)
98eb408

New changeset 79e9f5a by Miss Islington (bot) in branch '3.10':
bpo-45081: Fix __init__ method generation when inheriting from Protocol (GH-28121)
79e9f5a

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 #27545 (see [Lib/typing.py:1384](https://github.com/python/cpython/blob/main/Lib/typing.py#L1384)); 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