On 09/02/2010 04:12 PM, Ryan May wrote: > 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?
Yes: http://docs.python.org/release/2.4.4/lib/module-UserList.html But I agree that turning Figure.axes into a property with the getter generating a list probably will do the trick. Maybe you can use _ax_stack._elements? It looks like that may completely parallel the present Figure.axes. Stack, or a subclass or derivative, could store (ax, key) tuples instead of just the ax list. Then the equivalent of _seen could be generated on the fly as needed. (This is very fast.) This would completely eliminate the redundant storage of Axes references in Figure, and simplify some Figure methods. Eric > > 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 > ------------------------------------------------------------------------------ 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
