This is still broken even with#731. Once that is in, I will take a closer look at this.

There is a deeper problem here. Notice how the following code results in different results:

>>> import matplotlib.pyplot as plt>>> ax = plt.axes()>>> plt.axvline(0.5)>>> plt.plot([-0.1, 0, 0.2, 0.1])>>> print ax.viewLimBbox('array([[ 0. , -0.2],\n       [ 3. ,  1. ]])')

>>> import matplotlib.pyplot as plt>>> ax = plt.axes()>>> plt.plot([-0.1, 0, 0.2, 0.1])>>> plt.axvline(0.5)>>> print ax.viewLimBbox('array([[ 0.  , -0.1 ],\n       [ 3.  ,  0.25]])')

Essentially, the problem comes down to the fact that theaxes.ignore_existing_data_limits is not split intoignore x andignore_y components. Unfortunately I don't think we can get a solution to this before the1.2.x rc1, not least because it will need a change to some of the underlying cpp code in_path.cpp.

I should add, I don't think yourax.relim(); ax.autoscale() are strictly necessary. This should be what you get in the first place (at least, I can't get it to make any difference).

EDIT: Fixed attached code.

@pelson I'm struggling to see the difference in those two pieces of code.

Doh! I have edited it now.

I think the problem is deeper than@pelson suggests._path.update_path_extents is already able to ignore an axis simply by putting the values out of order (i.e.(max, min) rather than(min, max)) for that axis. This works as designed (even if it's not the cleanest way to do things).

The problem here is that the "default" data range is (0, 1) on both axes. So when you start with a vline, it (correctly) ignores the y axis, and sets the xrange to (0.49, 0.51) and leaves the yrange as (0, 1). The subsequent auto limit operation on the line plot does not know that the previous y limits aren't meaningful, and therefore keeps them as they are (since they don't need to be expanded to show the data).

I think the fix here is to updaterelim and theAxes.__init__ constructor to start with thenull data range rather than theunit data range. Then we know when a range isn't meaningful because it hasn't already been set to something finite.

I've attached a patch against 1.2.x (since this bug exists there, too), but I'm not entirely sure it isn't too big/risky for 1.2. I'd like to get this in for 1.3, however.

The attached PR also fixes#2061.

I've attached a patch against 1.2.x (since this bug exists there, too), but I'm not entirely sure it isn't too big/risky for 1.2. I'd like to get this in for 1.3, however.

I don't think this can go into v1.2.x, the change is functional (admittedly it wasunintentional behaviour in the first place).

The log scale test result is very different - its hard to know which one is expected, but it is without a doubt different behaviour. Would you mind providing your analysis on the test and why it was wrong?

Other than that, this is a nice solution - though I have to admit I'm not too fussed whether it makes it into thev1.3.x series or not.

Nice work@mdboom!

The log scale test adds aaxvline andaxhline, both at a position 24.1. In the old version, the resulting limits were (0, 100), since the initial limits on a plot were (0, 1), and the ax?line call added to it. In the new version, the resulting limits are (10, 100), since it should only include the decades around the given value. I think this is the correct behavior.

Yeah -- I think I agree about not including this in 1.2.x. I'll rebase and create a new PR for 1.3.x, also incorporating your other comments.

Yeah -- I think I agree about not including this in 1.2.x. I'll rebase and create a new PR for 1.3.x, also incorporating your other comments.

Great. And thanks for the explanation - I'm more comfortable with the change now. The only remaining work is to add an API change entry for the change.

Cheers,

Closing in favor of#2082.