New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always create Axes objects in examples #6822
Conversation
I usually favor avoiding the |
I am generally in favour of this, it works nicer with WCSAxes and our custom plotting wrappers. |
I don't really have an opinion here as long as we are consistent across the whole gallery. |
Grand - I'll go through and change everything then, and then take this back out of draft for some proper reviews on the actual implementation. |
9880dca
to
902a3a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially started replacing plt.subplots
with fig = plt.figure(); ax = fig.add_subplot()
but ran out of steam. I don't particularly like the inconsistency in the ways we create the figure, axes objects, but I do not think it is worth the added verbosity.
Co-authored-by: Will Barnes <will.t.barnes@gmail.com>
Our rules of thumb for gallery examples exist to "minimize verbosity and maintain consistency with the other gallery examples:". In some places consistency and verbosity are a trade off, including which flavour of the Matplotlib API we are calling.
Broadly the two options are:
Use
pyplot
(e.g.plt.xlabel
) where possible, and do not create Axes objectsUse
Axes
all the time, even when it would be possible to usepyplot
is a bit less verbose than 2., but this comes at the cost of having two ways of doing stuff in our gallery (e.g.
plt.xlabel()
vs.ax.set_xlabel()
. In my opinion consistency is more important than minimizing verbosity here, so I am proposing that we always create anAxes
object.I've converted one gallery example as an example of what this change would look like. Thoughts?