On Thu, Sep 2, 2010 at 8:33 PM, Benjamin Root <ben.r...@ou.edu> wrote: > On Thu, Sep 2, 2010 at 7:57 PM, Eric Firing <efir...@hawaii.edu> wrote: >> On 09/02/2010 01:21 PM, Benjamin Root wrote: >> > I think I understand the purpose for each container by itself, but not >> > for having all three together at the same time. At the very least, >> > maybe we can eliminate the list container? I think the difficulty there >> > would be with clearing the stack properly. >> >> You can't just blow away self.axes, because that is a public interface, >> and a convenient one. Maybe self.axes needs to be an object that can >> behave like a list, to preserve the public interface, but that >> underneath has the mechanisms required for the functionality now >> provided by self._seen and self._axstack, so that they can be eliminated. > > Right, of course... must have had a brain-fart moment. > > Creating another list-like object would probably be an ideal way to tuck > away self._seen and self._axstack. Especially given the public nature of > self.axes, we could never really be sure that self._axstack and self._seen > had all the axes listed in self.axes. I am gonna have to look through the > code and see what needs to be implemented. > > Does Python 2.4 support subclassing things like list?
Probably. But why not take advantage of properties as they were meant to be? You can make self.axes a property that generates the list from the self._axstack/self._seen only when accessed. We'd need to see if self.axes is used in any performance sensitive areas, but this seems like a *textbook* example of why properties are awesome. Is there any instance where adding to self.axes is a public API? Because given self._axstack/self._seen, it would seem that appending to this list would not by itself work. I'm willing to cook up the patch tomorrow if no one beats me to it. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
