Thanks for this. However, can you add a better title and move the cross reference to the description?

Per the discussion in#25220 there is some concern about doing this via this method and I agree with@ksunden if we are going to do this for one, we should do it for all.

@tacaswell let's come to a decision

• I do not think that there is consensus on the best way to fix this per[Doc]: Better document Axes.transData and other transXYZ attributes #25220 (comment)

I read the linked comment by@ksunden as +0.5 for properties. I'm also +0.5 on properties (and would make them read-only) I can't read any preference from your comments.

as I see it, we are going to properties. I think I implemented this in my last commit, and I'm ready to listen to what I should fix in my implementation. I also have a slightly naive question about failed tests: I don't quite understand how the changes I made caused errors in the tests (as far as I understand, the errors say about the conflict of Tkinter versions)

as I see it, we are going to properties.

I see it the same way, but@tacaswell doesn't seem so sure. Let's wait for his reply.

The test failures are unrelated. This is a configuration problem in the CI system for a specific version of OSX and tk.

I added this to today's call agenda.

Moving to properties to get documentation seems backwards to me (we are imposing a run-time cost for a doc-build-time problem). These have not changed is years, could we explicitly list them in the class docstring instead?

I‘m not sure I will make it to the call. Therefore, I add my 2cents right here:

Adding runtime cost just for doc would indeed sound odd, however

• This makes the properties read-only, which they conceptually could/should be. (Not clear how protective we want to be here, but it is certainly justifiable).
• The runtime cost is negligible in every practical usage scenario.

Overall I‘m +0.5 on properties. But it should alternatively be viable to list them in anAttributes section in the class docstringhttps://numpydoc.readthedocs.io/en/latest/format.html#class-docstring.

This makes the properties read-only,

The PR currently has setters for all 4.

Consensus from call

• go with properties
  • but do coarse bench marks to see if it matters
• option to look at read-only
  • would need a deprecation cycle
  • check how disruptive this would be
• consider renaming
  • Add PEP8-compliant aliases to transAxes, transData, etc. #11051 is prior art
• the docstrings are not yet clear
  • need to be more explicit about source and target coordinate systems
  • link to transform tutorial

Hi@AnanasClassic are you still interested in working on this one?