Can you just move the definition of ArtistInspector above Artist and avoid this deferred call? (And then _update_set_signature_and_docstring can be inlined into init_subclass.)

No strong opinion. But that's quite a bit moving of code, which makes digging in the history more complicated.

I don't think we can inline, because __init_subclass__ is not called by Artist itself, but we want to adjust Artist.set as well. (I wouldn't want to explicitly call __init_subclass__ on Artist. That's more confusing than an extra function.)

Let's leave things as they are for now.

I think it's more if cls.set != Artist.set (because cls could also be a subclass of a subclass that overrides set)

if cls.set != Artist.set: return does not work:

Consider the class hierarchy Artist -> A -> B. A get's a new set because there cls.set == Artist.set. But B will not get it's own set because B.set == A.set != Artist.set. Thus B.set will show only the properties of A not the additional ones of B.

We want to always define a new set unless the class definition itself contains a set (which none of our Artists does, but some third party might have implemented a dedicated set in their derived Artists and we don't want to break that). And I think the correct way to check this is checking cls.__dict__.

which none of our Artists does, but some third party might have implemented a dedicated set in their derived Artists and we don't want to break that

My point was that if thirdpartylib defines both A and B (in your example above) where A overrides set but B doesn't (and thus inherits A.set), I think(?) that your current implementation will correctly leave A alone, but not B?

Solved that via a flag on our autogenerated methods.

That said, I'm not 100% percent sure that this magic setter addition is what we want and downstream libraries expect. The alternative would be a class decorator, which we have to apply to all Artists; meaning adding this function would be opt-in. OTOH if nobody complains ...

I think this is fine for now, AFAICT this will not really affect 3rd-parties now that you added the flag?

Are non-linkable targets basically the methods defined on a private parent? If so, perhaps you can just check whether the class name starts with an underscore, rather than hard coding the entire list.

That's what I first thought (and checked with the print statement). Turns out it is more complicated than that.

As a general statement, a setter is not linkable if it has not doc entry. All non-private classes can (and now do) write documentation entries setters. We don't autodoc private classes, so there is no default place to document their setters. However, sublcasses may reimplement the setter and document that, or explicit entries can be created (e.g. for _AxesBase setters).

I'm not even sure this is the whole story. Anyway, I've chosen to only explicitly backout for the properties that sphinx was complaining about. The other ones are found one way or the other.