John, At >4600 lines, axes.py is getting unwieldy, as is the Axes class that makes up the bulk of it. I propose to reorganize it and split it into at least two files. The main organizational change would separate the functionality that is directly involved in manipulating the axes from the more specific plotting methods. This could be done, for example, by putting the former in an AxesBase class, and then letting Axes inherit that. At the very least it would be nice to rearrange the methods so that all the pure Axes manipulation methods are together at the beginning. What do you think? Eric
Eric Firing <ef...@ha...> writes: > The main organizational change would separate the functionality that > is directly involved in manipulating the axes from the more specific > plotting methods. This could be done, for example, by putting the > former in an AxesBase class, and then letting Axes inherit that. IMHO, it would make sense in the long term to make Axes a low-level class with a well-defined interface, and implement high-level plotting methods such as bar, boxplot, cohere, hist, specgram and what have you using that interface outside of Axes. Currently at least some of these methods "peek under the hood" by doing things like if not self._hold: self.cla() This looks like it will be a pain to maintain if the implementation details ever change. self._hold could probably be easily replaced by self.ishold(), but moving the methods to another class would help ensure that they stay kosher. -- Jouni
Jouni K Seppanen wrote: > Eric Firing <ef...@ha...> writes: > > >>The main organizational change would separate the functionality that >>is directly involved in manipulating the axes from the more specific >>plotting methods. This could be done, for example, by putting the >>former in an AxesBase class, and then letting Axes inherit that. > > > IMHO, it would make sense in the long term to make Axes a low-level > class with a well-defined interface, and implement high-level plotting > methods such as bar, boxplot, cohere, hist, specgram and what have you > using that interface outside of Axes. Currently at least some of these > methods "peek under the hood" by doing things like > > if not self._hold: self.cla() > > This looks like it will be a pain to maintain if the implementation > details ever change. self._hold could probably be easily replaced by > self.ishold(), but moving the methods to another class would help > ensure that they stay kosher. > Jouni, I think what you are proposing is a bit different from what John suggested in his subsequent message, but a common element is the separation of Axes nuts and bolts from fancier plotting. I will do that relatively simple job first; I think it will facilitate any subsequent more extensive refactoring. Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> I think what you are proposing is a bit different from what Eric> John suggested in his subsequent message, but a common Eric> element is the separation of Axes nuts and bolts from Eric> fancier plotting. I will do that relatively simple job Eric> first; I think it will facilitate any subsequent more Eric> extensive refactoring. This is an odd time to bring this up, when we are trying to prune the Axes class, but I am trying to remove any pure pylab functionality. To whit: 'setp' and 'getp' have been recently moved to matplotlib.artist, 'load' and 'save' to matplotlib.mlab, and so on. Basically, I want to have some ammunition when people complain that the OO interface is harder to use than the pylab interface :-) Which brings me to the 'axis' command. This is one of the few remaining truly useful pieces of pylab functionality. Should this not be a method of Axes (in the current, non-refactored understanding of Axes)? In any case, Eric, since you are intimately familiar with both axis and the phase-I refactoring of Axes, I think this would be a good time to make axis functionality available to non-pylab users, wherever it fits best. JDH
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> John, At >4600 lines, axes.py is getting unwieldy, as is the Eric> Axes class that makes up the bulk of it. I propose to Eric> reorganize it and split it into at least two files. Eric> The main organizational change would separate the Eric> functionality that is directly involved in manipulating the Eric> axes from the more specific plotting methods. This could be Eric> done, for example, by putting the former in an AxesBase Eric> class, and then letting Axes inherit that. At the very Eric> least it would be nice to rearrange the methods so that all Eric> the pure Axes manipulation methods are together at the Eric> beginning. Eric> What do you think? I don't want overarching ambitions to get in the way of a simple refactor, but.... I've discussed this with Fernando and Perry on a couple of occasions, and I think it would be useful to create high level Artists like LinePlot, ScatterPlot, BarChart, etc, that carried the lines, etc, etc around with them with useful configuration methods. The pylab.plot would be a thin wrapper to Axes.plot which would instantiate a LinePlot. A bit like what you recently did for the contour function. High level plot objects like this would allow us to easily support things like a FunctionPlot, which always returns the sin(x) at any given scale, with some configurable, intelligent way to determine the granularity of sampling at a given scale. So that is background on the general topic of refactoring axes.py. As for your specific suggestion, I have no problem with it. I have never had a problem with one large file since emacs and judicious use of search-forward and search-backward work fine for me. But I know that code better than most, and I think your proposed changes would make it much easier for people approaching the code for the first time to understand what is going on. It might also make it clearer how to pursue the grand refactor down the road. But I mention it now so you can think about it while you are working :-) JDH