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

[Travis Oliphant]

The idea of using constants instead of strings throughout NumPy is an interesting one, but should be pushed to another thread and not hold up this particular PR. 

I like the suggestion of Nathaniel.   Let's get the PR committed with a single-function interface.   I like having the array as the first argument to that function (it is more consistent).   They keyword can be called mode or method

Tim, what do you think of that?   Further developments can happen in a separate PR.

-Travis




On Mar 31, 2012, at 3:07 PM, Richard Hattersley wrote:

>>> 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion