Christopher Barker wrote: [...] > > Does internal MPL code rely on mlab? if so, it needs to be part of some > core lib that is stable enough to be a MPL dependency. >
Good question. With a couple of minor exceptions (which are easily handled), the only dependency is in axes methods that I don't think should be axes methods: xcorr, psd, etc. These are not the sort of core plot types that belong at the heart of mpl; they should be out on the periphery, in something like an optional toolkit. They are more analysis than plotting. I wanted to do a reorganization along these lines a long time ago, but never got around to it. The question of what should be an axes method has been raised in the context of John's mpl1 major rewrite ideas, but an incremental change might be feasible and worthwhile also. How much user code is relying on Axes.psd() etc? Probably not too much, and code modification required if these things were made functions that take an axes instance as the first argument would not be large. The methods could be moved out of Axes and converted to functions without affecting the corresponding pylab API. Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
