possible 1.2.1 regression in ax.axhline #1892

y-p opened this Issue Apr 9, 2013 · 5 comments


None yet

3 participants

y-p commented Apr 9, 2013

The 1 pixel workaround seems to work fine for single plots, but I may have
uncovered another regression. Not sure if related or not:

moved here from #1882.

In [1]: fig,ax=plt.subplots(2)
   ...: ax[0].bar(0,5,0.8,log=True, bottom=1,label='a')
   ...: ax[0].bar(1,5000,0.8,log=True, bottom=1,label='a')
   ...: ax[0].axhline(0, color='k', linestyle='--')
Out[1]: <matplotlib.lines.Line2D at 0x38b21d0>





neggert commented Apr 9, 2013

Can I ask again what the expected behavior is? Obviously the plot produced by 1.2.1 isn't correct, but it doesn't look like your line is visible in 1.2.0 either. And it shouldn't be. 0 is outside the bounds of the plot (and always will be for log plots).

y-p commented Apr 9, 2013

up till 1.2.1, IIUC, it was interpreted as a no-op,I understand it's incorrect technically,
but I'm not sure what breaking it achieved. Since it's already in 1.2.1, the horse has left
the stable, and I'll just fix it, I guess it will break other people's code as well though, and
you might get less friction by restoring the no-op behavior with the next point release. or not.

Let me see if fixing this shakes out anything else.

y-p commented Apr 9, 2013

Ok, everything seems to be working fine. Up to you whether to roll back the behaviour
for future release or close as wontfix.

Thank you.

neggert commented Apr 9, 2013

I guess that's up to the repo collaborators. To fix this without undoing the improvements in f6dfcea, I think it would require some work on the set_yscale('log', nonposy=True) code, which I don't know much about.

mdboom commented May 3, 2013

I think I'm going to declare this "won't fix". Thanks for the report, and thanks @neggert for the improvements that came out of the discussion.

@mdboom mdboom closed this May 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment