Darren Dale wrote: > On Thursday 24 April 2008 03:09:43 pm John Hunter wrote: >> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <[EMAIL PROTECTED]> wrote: >>> Darren, >>> >>> In an earlier thread on matplotlib-users, when this first came up, John >>> noted that numpy svn should be required for present mpl svn, so >>> instead of fixing the attempted workaround for 1.04 I took it out and >>> instead put a numpy version check in matplotlib.__init__. >> Just to make clear my thinking on this: since the svn trunk of mpl is >> a major refactoring and will be a major point jump when we release it >> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we >> can rely on all the nice features and fixes that have gone into that >> release. > > I've been installing numpy through various package managers and now I'll need > to figure out how to configure the build on fedora, ubuntu and gentoo in > order to use svn matplotlib. Was it a mistake for me to develop my > application using the matplotlib trunk? If I go through the trouble of > configuring the build environments for numpy on these various OS's, am I > going to discover that the numpy trunk is not backward compatible and is > causing problems with other applications? I know my own difficulties are not > sufficient reason to alter the development path of our fine library, but I > think this might be a mistake.
Darren, It is open for discussion. Here are some factors: 1) In my experience, numpy is easy to build from source--easier than matplotlib. 2) The numpy 1.1 release is coming soon--on the order of a week. I don't know how much that will help you. Maybe not much until distro packages catch up, which can take a long time. 3) There have been a lot of bug fixes between numpy 1.04 and 1.1. The main area of *slight* incompatibility is in the masked array package. The main practical difference is that some import forms that worked with 1.04 do not work with 1.1; e.g. you can't import ma from numpy.core because that is not where it is now, and it is sub-package, not a file. The ma internals are quite different (a masked array is now a subclass of ndarray), and the overall implementation is much improved, but functions and methods are highly compatible. Although I am sympathetic to the problems involved in making changes of this sort, I am also sympathetic to the problems of trying to keep something like mpl working with multiple versions of components like the numeric library. There were a lot of bugs and holes in the old numpy.ma. To me, it is a relief to be able to stick to the new version and forget about the limitations and quirks of the old. Ideally, it will mean that all of us can spend more time thinking about how to improve mpl and less time in duplicate testing and coming up with workarounds. Eric ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
