I (wrongly) expected mode to default to 'constant' with a value of 0, and not be forced to write an 8 character string everytime I call pad. I thought that was what scipy.ndimage.filters did, but those default to 'reflect', so maybe it is my expectations that need fixing...

That would be a sensible default--should I change it?

Do we have any reason to believe that "constant" is a better default than
anything else? (In the face of ambiguity etc.)
On 14 Jun 2014 18:25, "Stefan van der Walt" notifications@github.com
wrote:

That would be a sensible default--should I change it?

—
Reply to this email directly or view it on GitHub
#4808 (comment).

I don't think that applies here. If it did, the same argument could be used against almost any default value in any function. Do we have any reason to believe that the first axis is a better default than the last for ufunc's methods? That 'left' is a better side option for searchsorted than 'right' (Python's bisect actually defaults to bisect_right)?

I would argue that default values are about convenience, and have nothing to do with guessing or ambiguity. And when I think of padding, I think of FFT, convolution, correlation... which all make extensive use of 0 padding.

If one choice is more convenient, then that's not guessing. My concern is
that your justification seems ad hoc - if the choice is obvious, why does
ndimage make a different choice? If different choices are "obvious" to
different people than putting in a default is not a great idea.
On 14 Jun 2014 22:30, "Jaime" notifications@github.com wrote:

I don't think that applies here. If it did, the same argument could be
used against almost any default value in any function. Do we have any
reason to believe that the first axis is a better default than the last for
ufunc's methods? That 'left' is a better side option for searchsorted
than 'right' (Python's bisect actually defaults to bisect_right)?

I would argue that default values are about convenience, and have nothing
to do with guessing or ambiguity. And when I think of padding, I think of
FFT, convolution, correlation... which all make extensive use of 0 padding.

—
Reply to this email directly or view it on GitHub
#4808 (comment).

The convenience comes from not having to type some code sometimes, even if there is no obvious choice, e,g, the axis and side examples before.

Doesn't ndimage default to constant 0?

To me constant 0 sounds obvious in the sense, that all the others seem somewhat specific to the context, which np.pad does not have. Now if we fear that someone uses for example scipy.fi ilter and thinks that np.pad might have to do with filtering, too, then I would worry. Otherwise, I think we might as well allow it as default. Though if it is very rare, there may be no point in any case; but I doubt that.

I added constant as the default.

@njsmith Are you happy with this?

I'm at about -0.3 :-)

It's still not clear to me whether or not this is a good default (= obvious to everyone, consistent, etc.), esp. given that scipy.ndimage does in fact default to reflect. Generally I think we should aim to only provide defaults when there is some unique focal point, and this is a case where I can easily imagine that 50% of people are 100% convinced that constant is obvious b/c that's what gets used in their field, and a different 50% of people are 100% convinced that something else is obvious (I guess reflect). So I'd be happier if we'd asked the mailing list, or could point to other projects using the same, or something -- nothing major, but some data is better than no data.

OTOH, whatever, it's probably not an actively bad default and this is not a critical issue, so I'm not going to stand in the way if you guys are happy and want to go ahead.

It actually varies across scipy.ndimage--in some places you have reflect, in others constant. I think mostly to avoid boundary isues.

FWIW: I've used pad a few times in the last several months. Twice (blame the second time on my working into the wee hours, or on my increasingly sluggish brain cells) I didn't give the mode argument, expecting the default to be 'constant', and was surprised to get an error. In signal processing, padding pretty much means "pad with zeros". Easy enough to fix (if not remember!), but I'd be happy with the default mode being 'constant'.

Can you send a note to the list proposing this? That's our general policy
on proposed changes in api semantics; in this case, the check would be that
we don't have someone saying "wait but in XX area we have just as strong a
convention that pad means "reflect"" out something.
On Feb 2, 2016 7:57 AM, "Stefan van der Walt" notifications@github.com
wrote:

+1

—
Reply to this email directly or view it on GitHub
#4808 (comment).

More precedent - the padarray MATLAB function also pads with zeros by default.

Did this proposal ever make it to the mailing list? Was the discussion positive for setting the default mode to 'constant`?

+1 LGTM

@stefanv can you rebase?

For the record, this is not a backwards compat break (wasn't clear to me from the description). Hence the +1, just makes it easier, and yes this is the expected default behavior for most cases (signal/image processing) I'd say

CI failures, the override system seems to have made it harder to change signatures.

++python -c 'import os; import numpy; print(os.path.dirname(numpy.__file__))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.6/site-packages/numpy/__init__.py", line 145, in <module>
    from . import lib
  File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.6/site-packages/numpy/lib/__init__.py", line 27, in <module>
    from .arraypad import *
  File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.6/site-packages/numpy/lib/arraypad.py", line 965, in <module>
    def pad(array, pad_width, mode='constant', **kwargs):
  File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.6/site-packages/numpy/core/overrides.py", line 142, in decorator
    verify_matching_signatures(implementation, dispatcher)
  File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.6/site-packages/numpy/core/overrides.py", line 81, in verify_matching_signatures
    'different function signatures' % implementation)
RuntimeError: implementation and dispatcher for <function pad at 0x7f29c94da9d8> have different function signatures

This needs a change to

def _pad_dispatcher(array, pad_width, mode, **kwargs):
    return (array,)

right above the pad function definition.

All green and a number of +1's, merging. Thanks @stefanv, all