[Doc]: Document setters and getters from private superclasses

[oscargus]

Documentation Link

https://matplotlib.org/devdocs/api/image_api.html#matplotlib.image.AxesImage.set

Problem

The above is one example, but there are some cases where the superclass is common and therefore the corresponding setters and getters are not documented. For images, it is alpha, array, data, filternorm, filterrad, interpolation, interpolation_stage, and resample that has getters and setters with doc-strings, but since _ImageBase is private they are not shown.

Also, other common methods as can_composite, get_size, get_shape, and write_png are shown in the documentation.

Suggested improvement

Figure out how to add these in a good way. There are probably more classes where this happens.

[anntzer]

FWIW I think we should just make ImageBase public, as e.g. it makes sense to allow users to do isinstance(artist, ImageBase).

[timhoffm]

Sphinx is not well suited to document class hierarchies. I think the options here are:

• Make the base classes public. API-wise this should be mostly ok. All the public methods inherited from a private base classes are effectively public anyway. However, this does only marginally improve discoverability of the inherited methods. All you get is a working link to the base class
  
  but users have to follow that to see what's provided in there.

• You can use :inherited-members: in autodoc. But AFAIK, this just pulls everything together. You get very long lists of methods and there is no indication whether they are new or inherited. Also, this results in a lot of duplication.

Ideally, one would have a compact summary of inherited methods that links to the original documentation. Qt does something like this

https://doc.qt.io/qt-6/qpushbutton.html But I don't think sphinx has a way to achieve that.

[oscargus]

There will be a handful of links working with this and also the table in set will contain more links. So I think that there will be additional benefits.

Yes, the duplication is indeed an issue.

[timhoffm]

I agree, we should make ImageBase public.

[timhoffm]

#29561 Creates a hand-crafted minimal documentation for _CollectionWithSizes. It’s not very elegant or user friendly, but simple and better than not having the methods of the private bases documented at all.