Repository navigation
Being unable to specify the API for instantiating an object is a deleterious restriction for Protocols #110788
Description
Activity
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.Reacted by Jon Tyler@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.)So is there still a change that you're asking us to make?
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?
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.
Reacted by Jon Tyler@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.Reacted by Jon Tyler(Should be closed as completed as we did indeed implement the proposed change.)
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
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.