This hasn't been released yet, so should get a fix before 3.3 goes in (or be reverted)

did not know you could do axes spanning via add_subplot - is this a thing we want to advertise?

Well, I don't think we can break it, and it seems a useful feature. Note that this usage is also compatible with matlab's

This must rank among the ugliest carry-overs from the early attempt at Matlab compatibility. Can we at least document it as such--"un-Pythonic, unreadable, not recommended"?

Hmmm. Well I don’t know if the other ways of doing the same thing are so great that this deserves so much approbation. Making a gridspec and passing slices to add_subplot is a bit convoluted.

Wait, what?!? It took me 5 minutes to find out what fig.add_subplot(3, 2, (3, 5)) is supposed to do. This is far more crazy than subplot(325) (personal opinion).

I wouldn't be opposed deprecating it. Apparently we did neither have documentation nor tests. But if this get's documented instead, we should note that this is for MATLAB compatibility and maybe discourage it's use. IMHO We shouldn't judge our APIs (un-pythonic/unreadable).

Well, yes, I wasn't seriously proposing wording for our documentation. I would support deprecation in some form. I think #16603 is the basis for a better API for typical uses of add_subplot, but it doesn't include the ability of add_subplot to add one subplot at a time, potentially overlapping each other.

Maybe we need to think a little more about exactly what APIs we want to end up with in the long run. As time goes on, Matlab compatibility becomes less useful, and more of a burden.

The Matplotlib alternatives to ax = fig.add_subplot(3, 2, (3, 5)) are:

gs = fig.add_gridspec(3, 2)
ax = fig.add_subplot(gs[1:, 0])

or ax = plt.subplot2grid(3, 2, (1, 0), rowspan=2, fig=fig).

I substantially prefer the gridspec method of the three, but I don't consider any of them particularly awesome to justify deprecating any of them.