On Wed, 2005年09月14日 at 20:32 -0700, John Hunter wrote: > OK, great. Steve could you take a look at this when you get a > minute > and give some feedback about whether you think this is a god > idea. The patch works OK when I tried it, and the example displayed a button in the FigureCanvas. How is it extremely useful to place a widget on top of a FigureCanvas? I think a figure widget should just show figures, extra widgets can always be placed outside the figure widget. Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by GnomeCanvas) is more complicated and has a higher overhead. This week I read that the widget item in gnome-canvas does not work very well http://blogs.gnome.org/view/alexl/2005/09/14/0 Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Currently matplotlib already draws its widgets on the canvas, so this would allow a method to instead use native widgets in place of the matplotlib widgets when possible. Using native widgets has the advantage of response time and having a larger library at one's disposal. Even without the mapping of matplotlib->native widgets, it can be useful to easily put more controls to allow the plot to be altered (e.g. playing a movie, rerunning a sim, etc.) This can also be accomplished (at least with GTK) by adding another toolbar, but isn't always optimal. Is there an easy method to place widgets outside of the figure widget? Also, does this mean that matplotlib widgets should also not be drawn on the canvas? I checked on the link you gave, and it appears the problem occurs when scrolling is involved. Currently with how things are done, I don't think this will happen. Abe Steve Chaplin wrote: >On Wed, 2005年09月14日 at 20:32 -0700, John Hunter wrote: > > >> OK, great. Steve could you take a look at this when you get a >> minute >> and give some feedback about whether you think this is a god >> idea. >> >> > >The patch works OK when I tried it, and the example displayed a button >in the FigureCanvas. How is it extremely useful to place a widget on top >of a FigureCanvas? > >I think a figure widget should just show figures, extra widgets can >always be placed outside the figure widget. >Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by >GnomeCanvas) is more complicated and has a higher overhead. > >This week I read that the widget item in gnome-canvas does not work very >well >http://blogs.gnome.org/view/alexl/2005/09/14/0 > >Steve > >Send instant messages to your online friends http://au.messenger.yahoo.com > > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
On Sun, 2005年09月18日 at 16:45 -0400, Abraham Schneider wrote: > Currently matplotlib already draws its widgets on the canvas, so this > would allow a method to instead use native widgets in place of the > matplotlib widgets when possible. Using native widgets has the advantage > of response time and having a larger library at one's disposal. Even > without the mapping of matplotlib->native widgets, it can be useful to > easily put more controls to allow the plot to be altered (e.g. playing a > movie, rerunning a sim, etc.) This can also be accomplished (at least > with GTK) by adding another toolbar, but isn't always optimal. > > Is there an easy method to place widgets outside of the figure widget? Use the usual GTK+ widget placement methods - create a gtk.Window, add a VBox/HBox/Table etc and place the figure widget and other widgets in the container. This would be using the matplotlib OO interface like in examples/embedding_in_gtk2.py > Also, does this mean that matplotlib widgets should also not be drawn on > the canvas? Should matplotlib have turned itself into a widget library / GUI toolkit? I know that for a long time John resisted the temptation to add widgets to matplotlib and wanted matplotlib to focus on being a plotting library. I agree with this view and think the danger now is that matplotlib will become too big and bloated and harder to install (like the old SciPy?). I would prefer to see a 'matplotlib-core' which is a minimal module that focuses purely on plotting graphs. Other optional modules (like 'matplotlib-toolkits', 'matplotlib-widgets', etc) could then extend 'matplotlib-core' by providing extra features. > I checked on the link you gave, and it appears the problem occurs when > scrolling is involved. Currently with how things are done, I don't think > this will happen. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> Should matplotlib have turned itself into a widget library Steve> / GUI toolkit? I know that for a long time John resisted Steve> the temptation to add widgets to matplotlib and wanted Steve> matplotlib to focus on being a plotting library. I agree Steve> with this view and think the danger now is that matplotlib Steve> will become too big and bloated and harder to install (like Steve> the old SciPy?). Hey Steve, If I'm not mistaken, the complexity of the core matplotlib build has not changed in quite a while -- basically we've required zlib, png, freetype and C++ since 0.5. Yes, some backends require additional complexity (eg GTKAgg, the new WXAgg blit functionality) but you can simply turn these options off in setup.py if you don't need them; in the next few weeks I'm going to try and replace _gtkagg with pure python using python buffers. All of the changes to support blitting, widgets and so on have either been pure python or changes to existing extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size of the widgets module, which seems to bother you, is miniscule > wc lib/matplotlib/widgets.py 985 3004 32510 lib/matplotlib/widgets.py I don't want mpl to become a widget library. I did want to add some support for controlling the subplot parameters, a very frequent gripe. I could have say "dear backend maintainers, please add these sliders and buttons to make this tool" and we would still be waiting. I don't think any of the backends other than GTK* which I added have implemented the resize functionality I requested on Sept 14th. That doesn't really bother me too much, because I know people are busy with other projects, but to the extent that I can get low level functionality that lets the frontend do these things, I and others can can roll out functionality that benefits almost all users much more efficiently. I implemented sliders and buttons because I needed them. They are pure python, took me less than a day, do something useful, work out of the box across backends, and make up a small fraction of the total code size. Looks like a win-win to me. I implemented other widgets as an afterthought the same day as proof of concept, with the thought that if someone wants to make a *matplotlib tool* if they did it using the matplotlib widgets and events it would immediately be available to everyone. Most GUI work in python cannot be shared because it is tk specific, wx specific and so on, and I wanted to find a way around this problem. Steve> I would prefer to see a 'matplotlib-core' which is a Steve> minimal module that focuses purely on plotting Steve> graphs. Other optional modules (like 'matplotlib-toolkits', Steve> 'matplotlib-widgets', etc) could then extend Steve> 'matplotlib-core' by providing extra features. I think the distinction between plotting and interacting with your plot is not so clear. Sure, some small fraction of mpl users just generate static graphs, but the majority I would guess actually use things like matplotlib Events regularly (ie every time they use the pan/zoom tools). Should these be addons, or part of the core? I'm not opposed to this kind of packaging if it were done right (eg if everyone had something roughly equivalent to debian's apt. I think the vast majority of users want something that "just works". Nadia has been working on pulling all of the non-matplotlib dependencies out of the tree (CXX, Agg, png, zlib, pytz, dateutil) and revamping the build system to grab a tarball off the internet if a configure system doesn't detect them. This would make matplotlib CVS and the src distro much ligher, which I'm sure all the developers who regularly do CVS checkouts will appreciate since the damned pytz directories take forever. This will definitely be a step in the right direction, especially if we can get it to work across platforms. As far as widgets are concerned, I don' think they can be placed in an optional toolkit because the subplot tool requires them. At under 1000 lines of pure python, I also don't see the motivation. Contrast this with basemap, which is over 10MB with lots of extension code. Or would you like to see the toolbar and all of it's functionality rolled into an option addon? JDH
On Tue, 2005年10月04日 at 09:00 -0500, John Hunter wrote: > If I'm not mistaken, the complexity of the core matplotlib build has > not changed in quite a while -- basically we've required zlib, png, > freetype and C++ since 0.5. Yes, some backends require additional > complexity (eg GTKAgg, the new WXAgg blit functionality) but you can > simply turn these options off in setup.py if you don't need them; in > the next few weeks I'm going to try and replace _gtkagg with pure > python using python buffers. All of the changes to support blitting, > widgets and so on have either been pure python or changes to existing > extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size > of the widgets module, which seems to bother you, is miniscule > > > wc lib/matplotlib/widgets.py > 985 3004 32510 lib/matplotlib/widgets.py Once you have a GUI independent renderer and widget like backend_bases.RendererBase and FigureCanvasBase then you have the building blocks for writing a large GUI independent widget toolkit. But just because its possible does not mean you should do it. I can see that writing a small number of widgets is useful to mpl, but am concerned that it could easily snowball into a project that is not directly relevant to mpl. Abraham was suggesting that we provide a way to override these mpl widgets and use GTK widgets instead. I think that is unnecessary and undermines matplotlib's idea of using a GUI independent renderer and widget. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Steve, Darren Dale raised a question offline that I think will be of general interest to mpl devels, and that you are the person to answer: How do you see the future of a cairo backend as a prospective replacement for most or all of the primary mpl backends? What would need to be completed in cairo? Based on the cairo web page, I get the impression that quite a bit is still missing, including eps generation and genuine vector ps. But maybe the web page is just out of date. What would need to be done in mpl, and how hard would it be? Would mpl get slower if everything went through cairo? Any other considerations? Thanks. Eric
On Sat, 2007年01月06日 at 09:23 -1000, Eric Firing wrote: > Steve, > > Darren Dale raised a question offline that I think will be of general > interest to mpl devels, and that you are the person to answer: > > How do you see the future of a cairo backend as a prospective > replacement for most or all of the primary mpl backends? I think cairo could potentially be used to replace the pdf, ps, svg and gdk/gtk backends which would unify most of the backends and simplify a lot of the code. > What would need to be completed in cairo? Based on the cairo web page, I > get the impression that quite a bit is still missing, including eps > generation and genuine vector ps. But maybe the web page is just out of > date. Which web page is out of date? Where does it mention eps and ps, I couldn't find it. My general impression of the cairo "surfaces" is: ImageSurface/png - support is very good gtk/xlib - support is very good ps/pdf/svg are usable but less mature and still developing so there may be occasional problems drawing specific items ps - it used to embed bitmap images but now most output is vector based eps - is not supported yet, but may be in a future version > What would need to be done in mpl, and how hard would it be? The cairo backend can already be used for png, ps, pdf and gtk output so I don't think there would be much to do. Mostly, it needs testing - running all the mpl examples and checking the output looks OK. > Would mpl get slower if everything went through cairo? Not sure, you would need to run cairo and test it. It used to be much slower than Agg but more recent versions have had many optimisations applied and the difference is much smaller now. > Any other considerations? Some parts of mpl are Agg-specific and other parts (the whole drawing model) are designed around the gdk drawing style - this makes things harder and inefficient when using cairo. On Sat, 2007年01月06日 at 09:36 -1000, Eric Firing wrote: > One more question: how does the image quality of cairo compare to > Agg? > Is the antialiasing as good? Image quality looks OK to me, but I'm no expert. The web browser Firefox 3.0 (due to be released early in 2007) will use cairo for all rendering. Firefox requires a high level of graphics performance and the upcoming cairo 1.4 release is expected to provide that. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Steve, One more question: how does the image quality of cairo compare to Agg? Is the antialiasing as good? Thanks. Eric
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> My general impression of the cairo "surfaces" is: Steve> ImageSurface/png - support is very good gtk/xlib - support Steve> is very good ps/pdf/svg are usable but less mature and Steve> still developing so there may be occasional problems Steve> drawing specific items ps - it used to embed bitmap images Steve> but now most output is vector based eps - is not supported Steve> yet, but may be in a future version This was my impression too - that it used to be raster PS but now uses vector, but the web page seems to be claiming otherwise. In any case, the LGPL/MPL (mozilla public license not to be confused with matplotlib) seems to preclude our using it as our "core" renderer. Unfortunately, Agg itself recently switched over to a GPL license, but at least we have the 2.4 code base under BSD. We'll be in the same position as enthought and a few other companies who are relying on the BSD agg branch. At this state I think it advisable to make sure the cairo backend stays up to snuff in case the agg situation eventually becomes untenable, but agg is fairly stable and doesn't import anything, event the C++ standard library, so 2.4 should be good for some time to come. Hopefully the community (including us) will maintain it. Sigh, JDH
On Mon, 2007年01月08日 at 10:09 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > Steve> My general impression of the cairo "surfaces" is: > Steve> ImageSurface/png - support is very good gtk/xlib - support > Steve> is very good ps/pdf/svg are usable but less mature and > Steve> still developing so there may be occasional problems > Steve> drawing specific items ps - it used to embed bitmap images > Steve> but now most output is vector based eps - is not supported > Steve> yet, but may be in a future version > > This was my impression too - that it used to be raster PS but now uses > vector, but the web page seems to be claiming otherwise. Which specific web page says otherwise? Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Hi Steve, Eric, John, On Sunday 07 January 2007 04:44, Steve Chaplin wrote: > On Sat, 2007年01月06日 at 09:23 -1000, Eric Firing wrote: > > Steve, > > > > Darren Dale raised a question offline that I think will be of general > > interest to mpl devels, and that you are the person to answer: > > > > How do you see the future of a cairo backend as a prospective > > replacement for most or all of the primary mpl backends? > > I think cairo could potentially be used to replace the pdf, ps, svg > and gdk/gtk backends which would unify most of the backends and simplify > a lot of the code. This would really be a plus. The option to use latex for text layout would have to be completely reworked, if it could be supported at all. Not that this is a critical feature, but in my opinion it is still necessary at this point for producing the highest quality plots for publication. > > What would need to be completed in cairo? Based on the cairo web page, I > > get the impression that quite a bit is still missing, including eps > > generation and genuine vector ps. But maybe the web page is just out of > > date. > > Which web page is out of date? Where does it mention eps and ps, I > couldn't find it. > > My general impression of the cairo "surfaces" is: > ImageSurface/png - support is very good > gtk/xlib - support is very good > ps/pdf/svg are usable but less mature and still developing so there may > be occasional problems drawing specific items > ps - it used to embed bitmap images but now most output is vector based > eps - is not supported yet, but may be in a future version > > > What would need to be done in mpl, and how hard would it be? > > The cairo backend can already be used for png, ps, pdf and gtk output so > I don't think there would be much to do. Mostly, it needs testing - > running all the mpl examples and checking the output looks OK. I had to alter the following lines from backend_gtkcairo, from import matplotlib.backends.backend_cairo as be_cairo from matplotlib.backends.backend_gtk import * to import backend_cairo as be_cairo from backend_gtk import * in order to prevent the following traceback: Traceback (most recent call last): File "/usr/bin/ipython", line 27, in ? IPython.Shell.start().mainloop() File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in start return shell(user_ns = user_ns) File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in __init__ shell_class=MatplotlibMTShell) File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in __init__ on_kill=[mainquit]) File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in make_IPython embedded=embedded,**kw) File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in __init__ user_ns,b2 = self._matplotlib_config(name,user_ns) File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in _matplotlib_config from matplotlib import backends File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", line 55, in ? new_figure_manager, draw_if_interactive, show = pylab_setup() File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", line 23, in pylab_setup globals(),locals(),[backend_name]) File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", line 11, in ? import matplotlib.backends.backend_cairo as be_cairo AttributeError: 'module' object has no attribute 'backends' I only had a short time to work with backend_gtkcairo, but a couple of things caught my attention. mathtext support seemed to need some improvement, it looked like it was rendered as an image rather than as text. Also, imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe because the rgba ordering is different in agg and cairo? I'm not sure this is even the case, I'm taking a stab in the dark.) > > Would mpl get slower if everything went through cairo? > > Not sure, you would need to run cairo and test it. It used to be much > slower than Agg but more recent versions have had many optimisations > applied and the difference is much smaller now. > > > Any other considerations? > > Some parts of mpl are Agg-specific and other parts (the whole drawing > model) are designed around the gdk drawing style - this makes things harder > and inefficient when using cairo. I'm just thinking out loud here, brainstorming, but may be getting completely ahead of myself. Feel free to tell me so. If we made a mpl-pre1.0 branch, and reconstructed the drawing model, how much work are we talking about? Since gtk includes cairo now, couldn't a single gtk backend replace both gtk and gtkagg, while retaining the speed of the pure gtk backend? > On Sat, 2007年01月06日 at 09:36 -1000, Eric Firing wrote: > > One more question: how does the image quality of cairo compare to > > Agg? > > Is the antialiasing as good? > > Image quality looks OK to me, but I'm no expert. > > The web browser Firefox 3.0 (due to be released early in 2007) will use > cairo for all rendering. Firefox requires a high level of graphics > performance and the upcoming cairo 1.4 release is expected to provide > that.
Darren Dale wrote: > Hi Steve, Eric, John, > On Sunday 07 January 2007 04:44, Steve Chaplin wrote: >> On Sat, 2007年01月06日 at 09:23 -1000, Eric Firing wrote: >>> How do you see the future of a cairo backend as a prospective >>> replacement for most or all of the primary mpl backends? >> I think cairo could potentially be used to replace the pdf, ps, svg >> and gdk/gtk backends which would unify most of the backends and simplify >> a lot of the code. > > This would really be a plus. The option to use latex for text layout would > have to be completely reworked, if it could be supported at all. Not that > this is a critical feature, but in my opinion it is still necessary at this > point for producing the highest quality plots for publication. Playing around with using Cairo for something else, I once wrote some code to convert dvi to Cairo. The code I wrote probably isn't suitable for use by matplotlib, but it wasn't particularly difficult to write. The most difficult thing was finding the correct fonts - but I know people on this list have a lot of experience with that kind of problem anyway. It is possible the code would need to be in c/c++ for speed - my code was anyway so I don't know. I would offer to write something myself, but I'm leaving the field in which I use matplotlib around now and I wouldn't be able to maintain anything I wrote. Nicholas
On Monday 08 January 2007 11:51, Nicholas Young wrote: > Darren Dale wrote: > > Hi Steve, Eric, John, > > > > On Sunday 07 January 2007 04:44, Steve Chaplin wrote: > >> On Sat, 2007年01月06日 at 09:23 -1000, Eric Firing wrote: > >>> How do you see the future of a cairo backend as a prospective > >>> replacement for most or all of the primary mpl backends? > >> > >> I think cairo could potentially be used to replace the pdf, ps, svg > >> and gdk/gtk backends which would unify most of the backends and simplify > >> a lot of the code. > > > > This would really be a plus. The option to use latex for text layout > > would have to be completely reworked, if it could be supported at all. > > Not that this is a critical feature, but in my opinion it is still > > necessary at this point for producing the highest quality plots for > > publication. > > Playing around with using Cairo for something else, I once wrote some > code to convert dvi to Cairo. The code I wrote probably isn't suitable > for use by matplotlib, but it wasn't particularly difficult to > write. The most difficult thing was finding the correct fonts - but I > know people on this list have a lot of experience with that kind of > problem anyway. It is possible the code would need to be in c/c++ for > speed - my code was anyway so I don't know. > > I would offer to write something myself, but I'm leaving the field in > which I use matplotlib around now and I wouldn't be able to maintain > anything I wrote. Would you be willing to contribute this code to mpl? If so, please forward it to me off list. I would really like to have a look. Darren
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> This would really be a plus. The option to use latex for Darren> text layout would have to be completely reworked, if it Darren> could be supported at all. Not that this is a critical Darren> feature, but in my opinion it is still necessary at this Darren> point for producing the highest quality plots for Darren> publication. For many people this is absolutely the killer feature of mpl JDH
>>>>> "John" == John Hunter <jdh...@ac...> writes: >>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> This would really be a plus. The option to use latex for Darren> text layout would have to be completely reworked, if it Darren> could be supported at all. Not that this is a critical Darren> feature, but in my opinion it is still necessary at this Darren> point for producing the highest quality plots for Darren> publication. John> For many people this is absolutely the killer feature of mpl But I should add if cairo the cairo ps backend had good image support, we could put 6000 dpi images into the ps backend for the latex mathtext which would be fine. JDH
On Monday 08 January 2007 12:02, John Hunter wrote: > >>>>> "John" == John Hunter <jdh...@ac...> writes: > >>>>> > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> This would really be a plus. The option to use latex for > Darren> text layout would have to be completely reworked, if it > Darren> could be supported at all. Not that this is a critical > Darren> feature, but in my opinion it is still necessary at this > Darren> point for producing the highest quality plots for > Darren> publication. > > John> For many people this is absolutely the killer feature of mpl > > But I should add if cairo the cairo ps backend had good image support, > we could put 6000 dpi images into the ps backend for the latex > mathtext which would be fine. On the other hand, you would then lose the ability to search a pdf file for text in the figures. This is currently only possible using by setting ps.usedistiller to "xpdf", but it is a really nice feature.
Steve Chaplin wrote: > On Mon, 2007年01月08日 at 10:09 -0600, John Hunter wrote: >>>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: >> Steve> My general impression of the cairo "surfaces" is: >> Steve> ImageSurface/png - support is very good gtk/xlib - support >> Steve> is very good ps/pdf/svg are usable but less mature and >> Steve> still developing so there may be occasional problems >> Steve> drawing specific items ps - it used to embed bitmap images >> Steve> but now most output is vector based eps - is not supported >> Steve> yet, but may be in a future version >> >> This was my impression too - that it used to be raster PS but now uses >> vector, but the web page seems to be claiming otherwise. > Which specific web page says otherwise? http://cairographics.org/backends It looks like this simply has not been kept up to date. Eric
On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote: > > > What would need to be done in mpl, and how hard would it be? > > > > The cairo backend can already be used for png, ps, pdf and gtk output so > > I don't think there would be much to do. Mostly, it needs testing - > > running all the mpl examples and checking the output looks OK. > > I had to alter the following lines from backend_gtkcairo, from > > import matplotlib.backends.backend_cairo as be_cairo > from matplotlib.backends.backend_gtk import * > > to > > import backend_cairo as be_cairo > from backend_gtk import * > > in order to prevent the following traceback: > > Traceback (most recent call last): > File "/usr/bin/ipython", line 27, in ? > IPython.Shell.start().mainloop() > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in > start > return shell(user_ns = user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in > __init__ > shell_class=MatplotlibMTShell) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in > __init__ > on_kill=[mainquit]) > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in > make_IPython > embedded=embedded,**kw) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in > __init__ > user_ns,b2 = self._matplotlib_config(name,user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in > _matplotlib_config > from matplotlib import backends > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 55, in ? > new_figure_manager, draw_if_interactive, show = pylab_setup() > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 23, in pylab_setup > globals(),locals(),[backend_name]) > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", > line 11, in ? > import matplotlib.backends.backend_cairo as be_cairo > AttributeError: 'module' object has no attribute 'backends' The original matplotlib code is correct, you should be editing IPython and correcting their bug! Matplotlib does use a lot of relative imports which I think is bad style. See PEP 8 "Style Guide for Python Code" http://www.python.org/dev/peps/pep-0008/ - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 [7] is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. There was a recent "Coding Guide" thread on this list (which I admit I just skimmed through). Instead of reinventing the wheel, how about stating at the top of CODING_GUIDE that PEP 8 is the default style for matplotlib, and the following notes give in-depth matplotlib examples (or possibly override PEP 8 if necessary). Steve Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> Matplotlib does use a lot of relative imports which I think Steve> is bad style. Steve> See PEP 8 "Style Guide for Python Code" Steve> http://www.python.org/dev/peps/pep-0008/ Steve> - Relative imports for intra-package imports are highly Steve> discouraged. Always use the absolute package path for all Steve> imports. Even now that PEP 328 [7] is fully implemented in Steve> Python 2.5, its style of explicit relative imports is Steve> actively discouraged; absolute imports are more portable Steve> and usually more readable. I have never run into a problem with relative imports, though I don't object to removing them. Why are they bad style and what is the danger? Steve> There was a recent "Coding Guide" thread on this list Steve> (which I admit I just skimmed through). Instead of Steve> reinventing the wheel, how about stating at the top of Steve> CODING_GUIDE that PEP 8 is the default style for Steve> matplotlib, and the following notes give in-depth Steve> matplotlib examples (or possibly override PEP 8 if Steve> necessary). Agreed -- I'll update the coding style section to refer to this document, and provide a few comments in line. JDH
> I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? I had assumed because it would not be as obvious that the imports were local modules, but might be wrong... Best, Matthew
On Wed, 2007年01月10日 at 11:55 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> Matplotlib does use a lot of relative imports which I think > Steve> is bad style. > > Steve> See PEP 8 "Style Guide for Python Code" > Steve> http://www.python.org/dev/peps/pep-0008/ > > Steve> - Relative imports for intra-package imports are highly > Steve> discouraged. Always use the absolute package path for all > Steve> imports. Even now that PEP 328 [7] is fully implemented in > Steve> Python 2.5, its style of explicit relative imports is > Steve> actively discouraged; absolute imports are more portable > Steve> and usually more readable. > > I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? Its because you can unwittingly end up with module name clashes. There can be two different modules in two different directories with the same name and you import the wrong module by mistake. It happened to me once when I created a 'calendar.py' module and didn't realize that Python already has a calendar module. Its hard to debug because you get a traceback which makes no sense. >From PEP328 http://www.python.org/dev/peps/pep-0328/ Rationale for Absolute Imports In Python 2.4 and earlier, if you're reading a module located inside a package, it is not clear whether import foo refers to a top-level module or to another module inside the package. As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path. This is called an absolute import. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote: >> I have never run into a problem with relative imports, though I don't >> object to removing them. Why are they bad style and what is the >> danger? > > Its because you can unwittingly end up with module name clashes. There > can be two different modules in two different directories with the > same > name and you import the wrong module by mistake. Just wanted to chime in here -- with python 2.5, you can have your cake and eat it too: from .localpkg import Symbol1, Symbol2 from . import localpkg This disambiguates the "calendar.py" problem that you had (and that about 90% of python coders have had at least once in their lives). :) -Peter
On 1/10/07, Steve Chaplin <ste...@ya...> wrote: > On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote: > > I had to alter the following lines from backend_gtkcairo, from > > > > import matplotlib.backends.backend_cairo as be_cairo > > from matplotlib.backends.backend_gtk import * > > > > to > > > > import backend_cairo as be_cairo > > from backend_gtk import * > > > > in order to prevent the following traceback: > > > > Traceback (most recent call last): > > File "/usr/bin/ipython", line 27, in ? > > IPython.Shell.start().mainloop() > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in > > start > > return shell(user_ns = user_ns) > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in > > __init__ > > shell_class=MatplotlibMTShell) > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in > > __init__ > > on_kill=[mainquit]) > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in > > make_IPython > > embedded=embedded,**kw) > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in > > __init__ > > user_ns,b2 = self._matplotlib_config(name,user_ns) > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in > > _matplotlib_config > > from matplotlib import backends > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > line 55, in ? > > new_figure_manager, draw_if_interactive, show = pylab_setup() > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > line 23, in pylab_setup > > globals(),locals(),[backend_name]) > > > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", > > line 11, in ? > > import matplotlib.backends.backend_cairo as be_cairo > > AttributeError: 'module' object has no attribute 'backends' > > The original matplotlib code is correct, you should be editing IPython > and correcting their bug! Well, I'd be delighted to correct the ipython bug, if only I understood exactly what the problem was... As far as I can see, that code in ipython is simply calling # Initialize matplotlib to interactive mode always import matplotlib from matplotlib import backends inside a function (the _matplotlib_config method). I don't see a bug in that, but if you provide some pointers, I'll be happy to fix any issues that are on ipython's side of the fence. Cheers, f
On Mon, 2007年01月08日 at 11:24 -0500, Darren Dale wrote: > I only had a short time to work with backend_gtkcairo, but a couple of things > caught my attention. mathtext support seemed to need some improvement, it > looked like it was rendered as an image rather than as text. Also, > imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe > because the rgba ordering is different in agg and cairo? I'm not sure this is > even the case, I'm taking a stab in the dark.) cairo mathtext uses a method copied from gdk/gtk and does render an image. It needs updating to render text. imshow does look different on cairo and agg, and yes, It looks like an image format problem. cairo uses ARGB32 with pre-multiplied alpha, and the ARGB order depends on whether the machine is little- of big-endian. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> I had to alter the following lines from backend_gtkcairo, Darren> from Darren> import matplotlib.backends.backend_cairo as be_cairo from Darren> matplotlib.backends.backend_gtk import * Darren> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", Darren> line 11, in ? import matplotlib.backends.backend_cairo as Darren> be_cairo AttributeError: 'module' object has no attribute Darren> 'backends' My guess is that you were running your test code in which there was a "matplotlib" dir that was not *the* matplotlib install dir. Possible? JDH