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 byArtist itself, but we want to adjustArtist.set as well. (I wouldn't want to explicitly call__init_subclass__ onArtist. That's more confusing than an extra function.)

Let's leave things as they are for now.

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

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

Consider the class hierarchyArtist ->A ->B.A get's a newset because therecls.set == Artist.set. ButB will not get it's ownset becauseB.set == A.set != Artist.set. Thus B.set will show only the properties ofA not the additional ones ofB.

We want toalways define a newset 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 checkingcls.__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 overridesset but B doesn't (and thus inheritsA.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.