On 7/21/07, Paul Kienzle <[EMAIL PROTECTED]> wrote: > True > >>> min(a) > 1 > >>> min(b)
We should prefer the numpyisms anyway, a.max(), a.min(), a.absolute(). > > 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, ... > > > > it does defeat the purpose of your idea a bit, which is to have a set > > of commonly agreed on math symbols that everyone agrees on and we can > > always rely on with easy convenience. On the other hand, I am more > > comfortable being explicit here. > > That's acceptable. > > If the list of common items were shorter it would be easier. Now > whenever I use an expression I have to search the file for the math > import statement and check whether the particular symbol I need has > already been added to the list. For my own projects I started making > a standard import line I could cut and paste into every file, but it > came to more than 80 characters. I have no problem with multi-line imports, but Eric hates them. Apparently future python versions will support parentheses in imports to solve the multiline problem, I'm starting to come to the conclusion that the only reason to go with a module with a core set of math/numpy names is if we want to use the import * semantics, right? Otherwise, we might as well do from numpy import the, core, list, of, math, symbols rather than from matplotlib.math import the, core, list, of, math, symbols which only confuses the reader (are these symbols from numpy, math or internal to mpl?) So if we don't want to do that every time, and do want the convenience of having a core set of names available in pretty much every mpl module, we may have well have a "corenamespace" module that utilizes __all__ . Basically, we would be making a statement that we are flying w/o a net here but we know what we are doing. This would be documented in the CODING_GUIDE in the import section. The reason I bring up the idea of a core namespace is there are other functions that belong there along side asarray and pi (iterable and is_string_like come to mind). I'm not advocating this approach -- I'm just pointing out that I see no reason to have a separate module of numpy names if we are going to be explicit about the imports from there. In that case, we may as well explicitly import from numpy. JDH ------------------------------------------------------------------------- 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
