[Numpy-discussion] Style for pad implementation in 'pad' namespace or functions under np.lib

[Richard Hattersley]

>> 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