Repository navigation
DOC: Fix non-working code object references - #28825
QuLogic merged 1 commit into
Conversation
Sorry, something went wrong.
|
Note: Failing OSX and free-threaded tests are an unrealted CI issue. |
Sorry, something went wrong.
|
There's an exception for Axes.dataLim in doc/missing-references.json; can that be removed now? |
Sorry, something went wrong.
These were not rendered as links in the current docs, because the associated code objects do not exist as targets in the docs. For some reason, sphinx did not complain about it. But it does in some recent PRs (extracted from matplotlib#28560) - I'm unclear why, but anyway the correct solution is to change to explicitly listing the attributes.
| dataLim: mtransforms.Bbox | ||
| """The bounding `.Bbox` enclosing all data displayed in the Axes.""" |
There was a problem hiding this comment.
We need a place to put the docstring. IMHO a class-level annotation is the best location (though we normally don't write types in the py files).
Sorry, something went wrong.
|
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
git checkout v3.9.x git pull
git cherry-pick -x -m1 613c9c996c20e034de67126e3e1cc42d19835b1f
git commit -am 'Backport PR #28825: DOC: Fix non-working code object references'
git push YOURFORK v3.9.x:auto-backport-of-pr-28825-on-v3.9.x
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the Still Needs Manual Backport label once the PR gets merged. If these instructions are inaccurate, feel free to suggest an improvement. |
Sorry, something went wrong.
|
Let's not bother with a manual backport since 3.10 is not that far away. |
Sorry, something went wrong.
Follow up to matplotlib#28825.
Follow up to matplotlib#28825.
Follow up to matplotlib#28825.
Follow up to matplotlib#28825.
Follow up to matplotlib#28825.
These were not rendered as links in the current docs, because the
associated code objects do not exist as targets in the docs. For some
reason, sphinx did not complain about it. But it does in some recent
PRs (extracted from #28560) - I'm unclear why, but anyway the correct
solution is to change to explicitly listing the attributes.