Refactoring the axes module

Hello pythonistas,

We’ve just finished refactoring the axes module at the scipy sprint, and before merging we would like to inform developers of the changes. The axes module contained more than 9k loc, and a few classes. It used to be a file.

Now, it became a folder called “axes”. This module contains several private submodules:

  • _base.py: this private module contains a new class _AxesBase, that inherits from Artist. This new class contains all the methods except

the plotting and labelling methods. It is now 3k loc

  • _axes.py contains the Axes class. This class inherists from _AxesBase, and contains all the methods concerning plotting and labelling. It is now 6k loc

  • _subplots.py contains all the subplots directive.

The API has not changed: only the private methods from axes are not directly importable from axes anymore. All tests pass (travis shows a failed test on py3k, which I am not able to reproduce on my computer). The pull request can be seen here: https://github.com/matplotlib/matplotlib/pull/1931

Once this is merged, you may need to remove cleanly the previous installed version of matplotlib. Indeed, installing a package replaces the old files, but does not delete them. Thus, installing this new submodule will not remove the axes.py file. Hence, a manual deletion of this file is necessary.

Thanks,

N

Thanks Nelle. This is fantastic work and rather tedious given the size of
our axes.py file. I've done some sanity checks on this and worked with
Nelle to minimise any potential issues people may have. Some things have
changed. It's probably best to refer to the Github issue to see the paper
trail.

To reiterate, remember that you'll need to nuke your previous local
install. Installing over an existing mpl distribution will cause problems.
This is because `python setup.py install` will not remove the old axes.py
for you.

Thanks,
Damon

···

On Fri, Jun 28, 2013 at 5:20 PM, Nelle Varoquaux <nelle.varoquaux@...149...>wrote:

Hello pythonistas,

We've just finished refactoring the axes module at the scipy sprint, and
before merging we would like to inform developers of the changes. The axes
module contained more than 9k loc, and a few classes. It used to be a
file.

Now, it became a folder called "axes". This module contains several
private submodules:
- _base.py: this private module contains a new class _AxesBase, that
inherits from Artist. This new class contains all the methods except
the plotting and labelling methods. It is now 3k loc
- _axes.py contains the Axes class. This class inherists from _AxesBase,
and contains all the methods concerning plotting and labelling. It is now
6k loc
- _subplots.py contains all the subplots directive.

The API has not changed: only the private methods from axes are not
directly importable from axes anymore. All tests pass (travis shows a
failed test on py3k, which I am not able to reproduce on my computer). The
pull request can be seen here: https://github.com/matplotlib/matplotlib
/pull/1931

Once this is merged, you may need to remove cleanly the previous installed
version of matplotlib. Indeed, installing a package replaces the old
files, but does not delete them. Thus, installing this new submodule will
not remove the axes.py file. Hence, a manual deletion of this file is
necessary.

--
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

NB that this is in general a good reason to make a habit of using 'pip
install .' instead of 'python setup.py install'. pip *will* nuke old
versions for you, and thus gives you a better chance of importing the
code that was actually shipped.

-n

···

On Sat, Jun 29, 2013 at 8:13 PM, Damon McDougall <damon.mcdougall@...149...> wrote:

To reiterate, remember that you'll need to nuke your previous local install. Installing over an existing mpl distribution will cause problems. This is because `python setup.py install` will not remove the old axes.py for you.

Perhaps it would be a good idea to exercise the mpl toolkits with this since it is more likely for them to do more esoteric things with axes. Don’t forget Base map and possibly cartopy and pandas.

Cheers!
Ben Root

···

On Jun 28, 2013 5:20 PM, “Nelle Varoquaux” <nelle.varoquaux@…322…9…> wrote:

Hello pythonistas,

We’ve just finished refactoring the axes module at the scipy sprint, and before merging we would like to inform developers of the changes. The axes module contained more than 9k loc, and a few classes. It used to be a file.

Now, it became a folder called “axes”. This module contains several private submodules:

  • _base.py: this private module contains a new class _AxesBase, that inherits from Artist. This new class contains all the methods except

the plotting and labelling methods. It is now 3k loc

  • _axes.py contains the Axes class. This class inherists from _AxesBase, and contains all the methods concerning plotting and labelling. It is now 6k loc
  • _subplots.py contains all the subplots directive.

The API has not changed: only the private methods from axes are not directly importable from axes anymore. All tests pass (travis shows a failed test on py3k, which I am not able to reproduce on my computer). The pull request can be seen here: https://github.com/matplotlib/matplotlib/pull/1931

Once this is merged, you may need to remove cleanly the previous installed version of matplotlib. Indeed, installing a package replaces the old files, but does not delete them. Thus, installing this new submodule will not remove the axes.py file. Hence, a manual deletion of this file is necessary.

Thanks,

N


This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Perhaps it would be a good idea to exercise the mpl toolkits with this
since it is more likely for them to do more esoteric things with axes.
Don't forget Base map and possibly cartopy and pandas.

Thanks Ben. I already did some playing with mplot3d, but I haven't tried
axes_grid{,1} or basemap yet.

···

On Sat, Jun 29, 2013 at 4:10 PM, Benjamin Root <ben.root@...553...> wrote:

Cheers!
Ben Root
On Jun 28, 2013 5:20 PM, "Nelle Varoquaux" <nelle.varoquaux@...149...> > wrote:

Hello pythonistas,

We've just finished refactoring the axes module at the scipy sprint, and
before merging we would like to inform developers of the changes. The axes
module contained more than 9k loc, and a few classes. It used to be a
file.

Now, it became a folder called "axes". This module contains several
private submodules:
- _base.py: this private module contains a new class _AxesBase, that
inherits from Artist. This new class contains all the methods except
the plotting and labelling methods. It is now 3k loc
- _axes.py contains the Axes class. This class inherists from _AxesBase,
and contains all the methods concerning plotting and labelling. It is now
6k loc
- _subplots.py contains all the subplots directive.

The API has not changed: only the private methods from axes are not
directly importable from axes anymore. All tests pass (travis shows a
failed test on py3k, which I am not able to reproduce on my computer). The
pull request can be seen here: https://github.com/matplotlib/matplotlib
/pull/1931

Once this is merged, you may need to remove cleanly the previous
installed version of matplotlib. Indeed, installing a package replaces
the old files, but does not delete them. Thus, installing this new
submodule will not remove the axes.py file. Hence, a manual deletion of
this file is necessary.

Thanks,
N

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Thanks Nathaniel, I didn't realise pip could snarf a local checkout.
That's good to know.

···

On Sat, Jun 29, 2013 at 2:18 PM, Nathaniel Smith <njs@...503...> wrote:

pip *will* nuke old
versions for you, and thus gives you a better chance of importing the
code that was actually shipped.

--
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229