All the tests here need to pass

OK so this wasn't a bug before because centre was never called, but with the new version you had to make sure not to ignore ha etc? I guess that means this needs a minor API change note that "left" and "right" will now respect "ha" ie.. fixes a bug where ha was ignored if loc="left" or "right"

Are you sure that this catches ha and horizontal alignment properly?

Thanks for persisting with this!

Yep, you're right. The if/else blocks were never getting activated if loc wasn't passed and consequently kwargs wasn't getting updated. Now the functionality remains the same, except when ha or x is explicitly passed, in which case these would override what was earlier happening in the if/else blocks.

Only one small confusion that I can foresee - if both ha and horizontalalignment were passed, the earlier behaviour was to throw an error. Now, horizontalalignment is picked up if both are present. I can make it so that an error is thrown or we can add this to the docs.

I'm not sure - I thnk we want to raise these days on conflicting input, but we certainly do not do so consistently. @timhoffm ?

Under normal circumstances we raise via normalize_kwargs(). Likely, we should use that function here (no harm doing already other normalizations here as well), and then only use horizontalalignment.

Done. The error will now be thrown downstream via normalize_kwargs().

Done. The error will now be thrown downstream via normalize_kwargs().

I actually meant calling normalize_kwargs() in set_x/ylabel(). That way, you don't have to do all the song and dance with ha and horizontalalignment.

I actually meant calling normalize_kwargs() in set_x/ylabel(). That way, you don't have to do all the song and dance with ha and horizontalalignment.

@timhoffm Makes sense, much more readable now

I think we need one more review since there have been substantial changes singe @dstansby's approval.

What should the semantics be if you pass x but not horizontalalignment (or vice versa)? Currently, this picks the default for loc='center', but should it leave the other alone?

For the latter case, this can be greatly simplified, as there is already a check if x/horizontalalignment are passed, and this code should go into the else (and then it doesn't even need to worry about defaults.)

I guess depends on why they were kept separate originally. Was horizontalalignment just meant to be an English translation of x? If no, we have the answer right there. If yes, we would probably want to disallow calling the function with parameters like x=0, ha='right'. It would also call into question the value of ha when x != 0, 0.5 or 1

X and ha should be independent. Strings for loc are short for given x/ha pairs and specifying ha with loc should override the loc value of ha. Specifying loc and x should error.

Specifying loc+any other is already an error.

I think that means we should only apply these defaults if only loc is specified (or nothing is specified at all, which is the same), and therefore a) these defaults should be set in the above else only (which signifies that x/ha were not passed), and b) we don't need setdefault or normalize_kwargs because those would never be set.

Additionally, the check_in_list should be in the else because that is the only chance for it to be invalid.

@QuLogic I assume initialising loc = 'center' just before the else block is useless then too?

Yes, I think loc is set only because of the check_in_list outside the if.

I'm going to squash merge this, because we don't really need the back-and-forth to get tests working.