Repository navigation
Being unable to specify the API for instantiating an object is a deleterious restriction for Protocols #110788
Description
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.
Line 1430 in b4e48a4
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.
Activity
JelleZijlstra commentedon Oct 12, 2023
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 commentedon Oct 13, 2023
@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 theStateUpdateProtocolhere.)JelleZijlstra commentedon Oct 13, 2023
So is there still a change that you're asking us to make?
k98kurz commentedon Oct 13, 2023
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 commentedon Oct 13, 2023
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 commentedon Oct 13, 2023
@k98kurz, if you'd like to have the py311 behaviour on py310, you can use the
typing.Protocolbackport intyping_extensions.typing_extensionsis 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 fromtyping_extensionsin exactly the same way as the equivalent symbols fromtyping.JelleZijlstra commentedon Oct 13, 2023
(Should be closed as completed as we did indeed implement the proposed change.)