[bugfix] Use axes unit in scale bar if set by user.

[brittonsmith]

PR Summary

This is in response to an old email thread. If the user makes a plot, sets the axes unit, and then adds a scale annotation with a coefficient, the most appropriate behavior is to use the axes unit set by the user. The current behavior is to instead figure out an appropriate unit on its own, but this calculation does not take into account the user-provided coefficient. In other words, the following script creates a scale bar with units of Mpc, when Mpccm/h is probably more appropriate.

import yt
ds = yt.load('DD0046/DD0046')
p = yt.SlicePlot(ds, 'x', 'density')
p.set_axes_unit('Mpccm/h')
p.annotate_scale(corner='lower_right', coeff=5)
p.save()

This PR changes the behavior to use the axes unit in the case described above. This is a very minor issue, but I think this is the correct behavior.

PR Checklist

• pass black --check yt/
• pass isort . --check --diff
• pass flake8 yt/
• pass flynt yt/ --fail-on-change --dry-run -e yt/extern
• New features are documented, with docstrings and narrative docs
• Adds a test for any bugs fixed. Adds tests for new features.

[neutrinoceros]

Left a few suggestions. I'm happy to approve this once they are addressed and/or answered :)

[neutrinoceros]

I'm guessing you don't expect plot._axes_unit_names and self.coeff could be set to None independently, and maybe that's perfectly justified with the current state of the code base, but it looks like an implementation detail. I would feel more confident about this if/else block if all possibilities were taken into account. I assume that in the conditions I'm describing this should throw an error.

[neutrinoceros]

So I'm puzzled by this bit... It doesn't look like it's used anywhere. I recon it was there before your patch, but while you're at it, I assume it's safe to clean this up :)

[neutrinoceros]

So again, this was here before your patch, but I feel like it would be slightly more clear to have this as a default value in init(), because I'm worried that the block you're patching is getting a bit too large and harder to maintain. What do you think ?

[matthewturk]

I think since this is in response to some issues raised on the mailing list, we should err on the side of getting it in in its current state. @neutrinoceros would you be OK deferring the other fixes to later?

[neutrinoceros]

Honestly I don't trust us to remember this later, but if I misjudged the urgency of the fix, I'm fine with my nitpick remarks left unanswered :)

[matthewturk]

@neutrinoceros I've added a todo item to address the issues you raised, which I'm hoping to get to after finishing grades today.