JFR, that special logic could be reverted back, keeping added features for the Enum. Patch: gh-115937: remove extra processing for the __signature__ attribute by skirpichev · Pull Request #115984 · python/cpython · GitHub
Also, years after the PEP 362, the type check was added to solve inspect.signature doesn't always return a signature · Issue #66000 · python/cpython · GitHub. Perhaps, a managed attribute that check type in the setter could be better as a solution: then the exception will be raised in a right time and in a less surprising place.
Is there reasons why we would like to keep more complex handling for this special attribute?
Given above, the documentation could be rephrased as: “If the object has a __signature__ attribute and if it is not None, this function returns it.” Just as it was designed in the PEP, IIUIC.
Also, while in practice, probably, this will be tedious and inconvenient (see Signatures for extension modules (PEP draft), for some alternative) — this attribute actually the only way how people could support introspection for extension modules.
But it worth to note, that the PEP 362 has limitations, the inspect module can’t yet represent functions with multiple signatures (see e.g. Signatures, a call to action). Maybe this is an argument for we shouldn’t expose __signature__ as public? Wouldn’t be the __signatures__ as “list of Signature objects or None” - better?
Sorry, if this a bit off-topic and changes in logic shouldn’t be discussed here. @erlendaasland suggested me to start jet another thread on d.p.o, but I think it will be overkill:)