This looks like a good fix. You have some PEP8 errors (look under the travis py 3.6 tests). Thanks!

Thanks @AlexCav !

(my approval is moudlo the pep8 fixes)

Thank you for the quick approval! I have made the necessary pep8 fixes.

I fear this "fix" has broken the usual behaviour of the inset axes.

Running the following in a jupyter notebook (using matplotlib 2.2.0.post665.dev0+g00ae375cd)

%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.axes_grid1.inset_locator import inset_axes
xdata, ydata = np.arange(8), np.arange(8)

plt.figure(figsize=(6,3))
ax = plt.subplot(111)
ax.plot(xdata, ydata)
axins = inset_axes(ax, width=0.2, height=0.2, loc='upper left')

results in a huge figure of 18129 x 31028 pixels, which I can't even upload here to show it to you because it's too big. Running that code as script (without the notebook's default bbox_inches="tight") simply results in an empty plot.

The test that has been introduced here,

axins = inset_axes(ax, width=0.2, height=0.2, bbox_to_anchor=(1, 1))

runs fine. However, one cannot , make the bbox_to_anchor to default to anything other than None if the functionality of the loc parameter should be preserved.

I guess one needs to decide which transform should be standard and clearly document that for the other option to specify width and height a different transform needs to be chosen. See also #8952.

I think one proper thing to do here is move inset_axes into the main axes method and overhaul it, including better documentation. This is the one thing from axes_grid1 that I would use somewhat often and it seems like core functionality.

Not to say that a more short term fix to these inconsistencies would also not be welcome.

Btw can this be a new issue so it gets some attention?

I simply think that this is not the proper fix for the issue. Shouldn't it be reverted back and the old issue be reopened?

I agree that the fix is wrong, though I think I like the test, so I won't revert.

It seems that #8120 is just bad documentation and not using bbox_to_anchor correctly? It seems that if bbox_to_anchor is not None then the default should indeed be bbox_transform = parent._axes.transAxes if it is not supplied. But if bbox_to_anchor is not supplied, then the transform needs to stay None. #8952 explains things quite well.

It is all a bit confusing, not helped by quadruply nested subclasses. I'll try and have a PR in the next couple of days, if no one beats me to it, that tries to a) fix the error, b) make the documentation more clear, c) add an error check on the bbox argument so that it at least has all the elements needed to make a width and height.

As discussed in #10986 and above, this PR incorrectly assigned transAxes as the transform. While @AlexCav is correct, that will yield the a consistent application of the inset across different DPI output, it breaks old behaviour. So I'm reverting the merge...

OK, can't auto-revert... New PR