>> 1) The use of string constants to identify NumPy processes. It would >> seem better to use library defined constants (ufuncs?) for better >> future-proofing, maintenance, etc. > > I don't see how this would help with future-proofing or maintenance -- > can you elaborate? > > If this were C, I'd agree; using an enum would have a number of benefits: > -- easier to work with than strings (== and switch work, no memory > management hassles) > -- compiler will notice if you accidentally misspell the enum name > -- since you always in effect 'import *', getting access to > additional constants doesn't require any extra effort > But in Python none of these advantages apply, so I find it more > convenient to just use strings.
Using constants provides for tab-completion and associated help text. The help text can be particularly useful if the choice of constant affects which extra keyword arguments can be specified. And on a minor note, and far more subjectively (time for another bike-shedding reference!), there's the "cleanliness" of API. (e.g. Strings don't "feel" a good match. There are an infinite number of strings, but only a small number are valid. There's nothing machine-readable you can interrogate to find valid values.) Under the hood you'll have to use the string to do a lookup, but the constant can *be* the result of the lookup. Why re-invent the wheel when the language gives it to you for free? > Note also that we couldn't use ufuncs here, because we're specifying a > rather unusual sort of operation -- there is no ufunc for padding with > a linear ramp etc. Using "mean" as the example is misleading in this > respect -- it's not really the same as np.mean. > >> 2) Why does only "pad" use this style of interface? If it's a good >> idea for "pad", perhaps it should be applied more generally? >> numpy.aggregate(MEAN, ...), numpy.group(MEAN, ...), etc. anyone? > > The mode="foo" interface style is actually used in other places, e.g., > np.linalg.qr. My mistake - I misinterpreted the API earlier, so we're talking at cross-purposes. My comment/question isn't really about pad & mode, but about numpy more generally. But it still stands - albeit somewhat hypothetically, since it's hard to imagine such a change taking place. Richard _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion