[Numpy-discussion] Style for pad implementation in 'pad' namespace or functions under np.lib
Thu Mar 29 11:52:01 CDT 2012
On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith <firstname.lastname@example.org> wrote:
> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <email@example.com> wrote:
>> While namespaces are a really good idea, I'm not a big fan of both "module"
>> namespaces and underscore namespaces. It seems pretty redundant to me to
>> have pad.pad_mean.
>> On the other hand, one could argue that pad.mean could be confused with
>> calculating the mean of a padded array. So, it seems like the function
>> names need to be called something more than just "mean, median, etc."
>> Something like padwith_mean, padwith_median, etc. actually makes more sense.
>> Or pad.with_mean, pad.with_median. The with_ in this case is not really
>> a "namespace" it's an indication of functionality.
> Perhaps it should be
> pad(..., mode="mean")
> , mode="" is only a few more characters than _with_, and this would
> make it much easier to write functions whose API looks like:
> wavelet_decompose(..., pad_mode=....)
> Also it would solve the namespace question :-).
> -- Nathaniel
...And on looking at the pull request for a bit, it would let us
combine 10 distinct single-line functions that (with highly redundant
docstrings) take up ~600 lines of code. The interfaces are *almost*
identical; the exceptions are:
-- "reflect" and "symmetric" take and "even"/"odd" argument
-- "pad_constant" takes an argument specifying the constant to pad with
-- "pad_linear_ramp" takes an argument specifying the end value of
the linear ramp
The first two can be easily handled by just combining it into the
mode, so we have "reflect", "reflect_odd", "symmetric",
"symmetric_odd", so that just leaves two mode-specific arguments. I
wouldn't feel bad about leaving those in as unused arguments for most
modes. We might even want to combine them into a single argument --
normally I'm against such "simplifications", but the semantics really
are quite similar.
And final advantage: we could later extend this interface to also
support mode=user_specified_callable for custom padding modes, since
this is basically how the underlying code already works. (Though I'm
not quite sure the interface for the individual pad mode functions
like _mean and _median is the one we'd want to expose to users.)
More information about the NumPy-Discussion