On Fri, Mar 30, 2012 at 8:35 AM, Richard Hattersley <rhatters...@gmail.com> wrote: > I like where this is going. > > Driven by a desire to avoid a million different methods on a single > class, we've done something similar in our library. > So instead of > thing.mean(....) > thing.max(...) > etc. > we have: > thing.scrunch(MEAN, ...) > thing.scrunch(MAX, ...) > etc. > Where the constants like MEAN and MAX encapsulate the process to be > performed - including a reference to a NumPy/user-defined aggregation > function, as well as some other transformation details. > > We then found we could reuse the same constants in other operations: > thing.scrunch(MEAN, ...) > thing.squish(MEAN, ...) > thing.rolling_squish(MEAN, ...) > > So I have two minor concerns with the current proposal. > 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. 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. -- Nathaniel _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
