John Hunter wrote: [...] > functions or array functions here, eg math.sqrt vs numpy.sqrt? Also, > a few of your symbols clash with python builtins (min, max, abs) which > is best avoided. Finally, how would you feel about allowing these > symbols in the module namespace, but w/o the import * semantics, eg, > for these symbols we do > > from mpl.math import exp, sin, pi, sin, cos, ...
There is no point in this; better to import these directly from numpy, if that is what is wanted. But sometimes we actually want a masked array version. For many of these things there are up to 5 different possible sources: (builtin, if not math or cmath) math cmath numpy numpy.ma maskedarray Sometimes functions from the different sources do the same thing, but usually at different speeds, and sometimes they don't do the same thing at all. In most cases we want, or at least can manage with, either the numpy version or one of the masked versions, presently accessed via numpy.numerix.npyma, which is imported via import numpy.numerix.npyma as ma The recently introduced policy of simply being very explicit *does* work; when looking at an expression one always knows which functions are being invoked. Like Paul, I recoil a bit at the clunky appearance, but apparently unlike Paul, I find the explicitness helpful--especially since I am very conscious of the need to use masked versions in some places. There is nothing inherently wrong with being explicit by importing some symbols into the module namespace with lines at the top, but this works best if there are not too many of those symbols, if they don't clash with symbols from other modules one is using, and if the module is not too long. A prime example of a case where these conditions are violated is axes.py. Consider two possible policies: Common to both: c1) Never mask a builtin. c2) Use nonconflicting names, specifically, always use amin and amax from numpy or ma instead of min or max. c3) Use methods in preference to functions where possible; this has the advantage of taking care of masked or ordinary cases automatically. 1) Present: always be explicit: npy.sin or ma.sin or math.sin or cmath.sin. (For scalars, the math module functions are much faster than the numpy versions, but on the other hand they should be called seldom enough that this would never matter.) 2) Pick a set of math symbols that may be imported directly from numpy at the top, and either import all routinely, or import as needed. Use explicit "ma." when masked versions are needed. (Depending on design decisions, this could end up being much of the time.) Suboptions: 2a) Include other very common symbols such as array, asarray, newaxis, ones, zeros. 2b) Use something like "from matplotlib.numpyapi import *" to accomplish all of this. This has the advantage of consolidating the names in one place, so one can easily see what the standard names are, and one doesn't have to keep checking the top of the file to see whether an additional name needs to be added. I can accept either of these, so long as we can decide and then get on with life. John, Norbert, and I have already spent time converting some modules to option 1. There was some discussion of this a couple months ago when John first proposed it. Now we have some experience. Another conversion is OK, but let's get it straight and make it the last one. Or leave it. My impression is that other projects typically use something closer to option 2. Prior to our partial conversion to option 1, the tops of our modules were an ugly mess. Option 1 represented a substantial cleanup and clarification--but with the penalty of uglier math expressions. I'm sorry I don't have a strong recommendation yet; I hope the above overly-long text helps the decision process nevertheless. Looking at the options without consideration of prior decisions and work done, my present preference is *mildly* towards option 2 with both suboptions. The biggest problem is the slippery slope--this can easily end up with more and more symbols being added until one is effectively doing "from numpy import *", and I don't want to do that. 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
