Woah, I thought that splitting a class wasn't possible in Python. I suppose that's because I had never really utilised relative imports to their full potential. Thanks for this work,@NelleV.

I'm not able to reproduce the failing tests on py3k.

Great work Nelle. I'm going to do some playing locally with the OO interface just to make sure I can create different types of Axes objects.

I'm going to trust you thatall the subplotting stuff was ported over correctly.

I looked atglobals().keys() (sorted) before and after these changes and this is the diff:

--- before.rst  2013-06-29 11:01:12.000000000 -0500+++ after.rst   2013-06-29 11:03:11.000000000 -0500@@ -25,24 +25,20 @@ _iii _oh _sh-allow_rasterization cbook division docstring exit-font_manager get_ipython help is_sequence_of_strings is_string_like-itemgetter iterable itertools ma martist math matplotlib-maxis mcoll mcolors mcontour@@ -54,8 +50,6 @@ mpatches mpath mquiver-mscale-mspines mstack mstream mtable

Most of these are other matplotlib's module, and some ipython specific stuff. Two functions are "missing" (they are both from the cbook module):

• is_sequence_of_strings

• is_string_like

  I think that the code is cleaner this way (in the sense that only methods that should be in the namespace are). I can add in the documentation where those modules and functions are imported from, in order for people to fix their code quickly if by mistake they used them from the axes module.

I've also constructed anAxes object programmatically using the OO interface and a basicplot command works as expected.

importmatplotlibmatplotlib.use('pdf')frommatplotlib.figureimportFigurefrommatplotlib.backends.backend_pdfimportFigureCanvasPdfasfigcanfig=Figure()can=figcan(fig)ax=fig.add_axes([0.1,0.1,0.8,0.8])ax.plot([1,2,3])fig.savefig('asdf.pdf')

3D axes also works using the usualfrom mpl_tookits.mplot3d import Axes3D and setting the projection on theax object.

Notice therepr (orstr, I can never remember which one) has changed to<matplotlib.axes._axes.Axes at 0x10a0b91d0>. That said, it's reasonable for us to assume that people don't depend on that output.

I've documented the changes in the namespace of the axes module. I think this is ready to be merged.

Thanks@NelleV. I think anybody relying on, for example,martist from the axes namespace has sufficient information to update their scripts inapi_changes.rst. Though this may break for some people, it wasn't well documented initially.

I'm going to merge this now. We should be aware of possible issues, but I think we've done the right thing here.

Merged. With much trepidation.