Ben, Thanks for the suggestions. I've updated the code accordingly. I tend to use **kwargs because it enforces passing arguments in by keyword, but your point on IDE friendliness is well taken. Someday, we'll move to Python 3 with its support for keyword-only arguments...
I've also added a license block releasing the code under the MIT license. If there's a reason it should be released under a different license as well, let me know. Ray On 2/12/2011 1:01 PM, Benjamin Root wrote: > > > On Fri, Feb 11, 2011 at 3:06 PM, Ray Speth <sp...@mit.edu > <mailto:sp...@mit.edu>> wrote: > > Hi, > > I wrote a script to generate streamline plots using matplotlib a while > ago, and this post inspired me to finally clean it up a bit. The code is > available at http://web.mit.edu/speth/Public/streamlines.py and you can > see an example of its output at > http://web.mit.edu/speth/Public/streamlines.png > > I'd be happy to have it find a home in matplotlib if it would be useful > to other people there. > > Ray > > > Ray, > > That is absolutely beautiful work there. > > At the very least, I would like to see this added to the gallery or the > cookbook. The code is very nicely commented and documented. Just a few > points that come to mind. > > First, consider the possibility of using asanyarray() instead of > asarray(). The big usecase for asanyarray is the use of masked arrays. > > Second, I am personally against call signatures that are just "**kwargs" > and then popping off the arguments at the beginning of the method. So > long as the default value is not a mutable object, then put those > arguments in the call signature with the default values. It is much > more IDE and documentation-friendly this way. > > Third, I would think that using plt.gca() would be better than > plt.axes() just in case the user is using subplots. gca() will create > an axes if none exists already. > > Lastly, you should do ax.plot() instead of plt.plot() since you have > already retrieved the axes object. This way, in case the axes object > passed in is not the currently active axes, it would still work. > > The difficulty in getting this included into matplotlib proper (and the > same goes to the other thread about streamgraphs) is that these plots > are done in an object oriented rather than procedural approach. > Personally, I would like to see (one day) a refactor of matplotlib where > everything plotable is an object that gets placed into the axes object > (which, itself is a plotable that gets placed in a figure...). While > the current code isn't too far from that concept, the interface is > ultimately procedural. > > @everyone else: > The big reason I see for a future refactor to an object-oriented > approach is that plots are getting more complicated, and we can't just > keep on adding more methods to the axes object. A more object-oriented > approach would allow for complex graphs to be placed into their own > modules, and yet still be treated the same as any other plotting > method. It would also make it easier for others to extend matplotlib's > plotting features. > > Ben Root > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
