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

Travis Oliphant travis@continuum...
Thu Mar 29 12:07:34 CDT 2012


On Mar 29, 2012, at 11:52 AM, Nathaniel Smith wrote:

> On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
>> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <travis@continuum.io> 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.)


I like the direction this conversation is going.      A single pad function in numpy or numpy.lib is a good idea. 

-Travis



> 
> -- Nathaniel
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



More information about the NumPy-Discussion mailing list