Py3fy webagg/nbagg. #10708
Py3fy webagg/nbagg. #10708
Conversation
|
Do we not test any of NBAgg? |
|
No idea whether we do... |
|
I think that might be what the notebook in the |
|
Now there are some tests :) |
| try: | ||
| self.figure.draw(renderer) | ||
| super().draw() |
There was a problem hiding this comment.
... this is pretty different. Does it do the same thing? Why just call super draw instead of the figure? Just trying to understand, not saying its wrong....
There was a problem hiding this comment.
If you're using Agg, this resolves to https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_agg.py#L414 which gets a cleared renderer, handles the locking and calls self.figure.draw(self.renderer).
Of course the not-so-secret objective here is to make it possible to swap in mplcairo's renderer. For that, the idea is as usual to push as much the renderer-specific code back to the super-class.
There was a problem hiding this comment.
Makes sense. I did find super().draw() a bit opaque.; ie. why not just self.draw()?
There was a problem hiding this comment.
well that would be an infinite loop...
super().draw() means (approximately) "call the draw method but don't look it up on this class, look it up on the base class [in this case, FigureCanvasAgg] instead" (check up e.g. "python super mro" for details)
|
If you rebase this so your new tests are included, will the codecov go up? Did you test this w/ your new tests? |
(The locking of RendererAgg is already done by the super class, and thus redundant here.)
|
rebased. |
(The locking of RendererAgg is already done by the super class, and thus
redundant here.)
PR Summary
PR Checklist