On Mar 29, 2012, at 11:52 AM, Nathaniel Smith wrote: > On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith <n...@pobox.com> wrote: >> On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <tra...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
