Being unable to specify the API for instantiating an object is a deleterious restriction for Protocols

[k98kurz]

It makes no sense to be unable to specify the interface for instantiating a class object. The only way around this at the moment is to specify a class method that serves the literal same purpose as the __init__ method, then relying upon it instead of the normal mechanism for object instantiation.

This is one of the poorest design decisions in CPython in my opinion. It breaks introspection tools that seek to document the required __init__ API, and it breaks even the concept of checking if the required __init__ API is followed. As I said, the only way around this is to create a new class method that merely replicates what the built-in __init__ method is supposed to do.

cpython/Lib/typing.py

Line 1430 in b4e48a4

def _no_init_or_replace_init(self, *args, **kwargs):

If there is some justification for this frustrating antipattern, please let me know. I do not see anything about this in PEP-544, though I only skimmed it looking for an answer and did not study it thoroughly.

[JelleZijlstra]

Can you give some specific examples of code you think should work but doesn't? You may be interested in #31628 (released in 3.11 and 3.12) that preserves __init__ methods in Protocol declarations.

[k98kurz]

@JelleZijlstra I thought I was going insane, because I had documentation generated from a Protocol that somehow preserved the __init__, but it disappeared when I tried regenerating the documentation. (I made a tool called autodox that uses introspection to generate markdown documentation for a module, and this is the tool I use for generating documentation for my other packages.)

My specific case is the interface for encoding state deltas in delta-state CRDTs. I have a library which implements 12 of them (crdts), and I am preparing to push an update. I encountered this strange behavior while updating the documentation, when I noticed that the __init__ documentation for the interfaces had disappeared. (The interface in question is the StateUpdateProtocol here.)

[JelleZijlstra]

So is there still a change that you're asking us to make?

[k98kurz]

It is kind of weird for a package to have differing behavior between 3.10 and 3.11. Is there a way to patch this specific change into 3.10, or does that go against policy?

[JelleZijlstra]

We made this change only on 3.10 because we judged it too risky for a bugfix. (If we fixed it in 3.10, earlier bugfix versions of 3.10 would behave differently than later ones, which is even more likely to lead to confusion.) Now, 3.10 is in security fix-only mode, so it's definitely too late to make the change in 3.10.

[AlexWaygood]

@k98kurz, if you'd like to have the py311 behaviour on py310, you can use the typing.Protocol backport in typing_extensions. typing_extensions is a third-party package dedicated to bringing newer typing features to users of older Python versions. It's mostly maintained by CPython core devs (including Jelle and myself), and type checkers understand symbols from typing_extensions in exactly the same way as the equivalent symbols from typing.

[JelleZijlstra]

(Should be closed as completed as we did indeed implement the proposed change.)