Hi, On Fri, 2008-07-18 at 09:24 -0500, John Hunter wrote: > On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
> I'm not a huge fan of mixins. We use them occassionally, eg for > FigureCanvasGtkAgg and their are some good uses for them, but they can > quickly lead to overly complex code so should be avoided where > possible. I find the "deeper hierarchy" approach more appealing here, > but am not sure if it is viable. For example > > class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg) > Actually the case of GTKAgg is an interesting one. I have FigureCanvasGTK inherit the mixin, but this doesn't cascade to GTKAgg because it gets overloaded with the non-user-interface versions from FigureCanvasAgg leading calls to ginput to produce an error. Adding the mixin to the end of GTKAgg's inheritance list didn't work because it seems that python decides that Agg has already overwritten the same mixin included by GTK and ignores the mixin inheritance at the end of the list (this surprised me, but it appears to work that way). One could always force it to use the right ones by adding functions that point to the mixin versions, but this seems less elegant than inheritance. In this and similar cases, is the order of inheritance important? Changing it to (FigureCanvasAgg, FigureCanvasGTK) should fix the problem. > inherits from an interactive and a non-interactive backend, which is a > good example of how quickly multiple mixin inheritance can get tricky. > I think perhaps it is best to create no new classes, put the base > methods in the FigureCanvasBase, make the default behavior > non-interactive, and then overrride them for the GUI backends. Any > problems with this? > Well, yeah. I think this would mean a lot of the same code in many backends. I also like the idea of a deeper hierarchy with a FigureCanvasUserInterface class that inherits FigureCanvasBase but adds functional start/stop_loop_events because it would allow for a simple cbook test for a working user interface: isinstance(mycanvas,FigureCanvasUserInterface) A deeper hierarchy won't help the inheritance problem for GTKAgg though. > Finally, the term "interactive" is a bit confusing and overloaded > here, since "is_interactive" in mpl means someone is working from the > interactive shell and we want to update the figure on every command > (if draw_if_interactive). For clarity, I think we should refer to > this as a "user interface" backend or something like that,. I know in > parts of the backend code we have the designation of interactive > backends, but these variables should probably be renamed to avoid > further confusion, since the other use of interactive is already > enshrined in the frontend api and rc file. > I agree. > JDH -- ********************************** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ********************************** ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
