[Numpy-discussion] Feedback on new argument positions for ma.dot and MaskedArray.dot
njs at pobox.com
Mon Nov 9 19:54:01 EST 2015
On Mon, Nov 9, 2015 at 4:43 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> On Sun, Nov 8, 2015 at 8:43 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Nov 8, 2015 6:00 PM, "Eric Firing" <efiring at hawaii.edu> wrote:
>> > I also prefer that there be a single convention: either the "out" kwarg
>> > is the end of the every signature, or it is the first kwarg in every
>> > signature. It's a very special and unusual kwarg, so it should have a
>> > standard location.
>> For all ufuncs, out arguments come first immediately after in arguments,
>> so +1 for doing that for consistency.
> Agree that that is what to shoot for. The particular problem with `ma.dot`
> is that it already has the `strict` argument where the new `out` argument
> should go. I propose the following steps.
> 1. For backward compatibility, start by adding new arguments to the end
> 2. Later raise FutureWarning on positional arguments that are out of place
> 3. Then make all but early arguments keyword only
> Once we have keyword only for a while, it would be possible to add some
> arguments back as positional arguments, but it might be best to keep them as
> keyword only as suggested above.
> For the current PR, this means that the dot method will have positional
> arguments in a different order than ma.dot. Alternatively, out could be made
> keyword only in both, although that would require fixing up some tests.
> There is really no magical solution that avoids all difficulties that I can
> Unless a consensus develops otherwise, I will pursue step 1. and go for a
> 1.10.2rc tomorrow.
If we're adding it in a funny place to ma.dot now (the end of the
arglist) with the plan of changing it later, then why not make it
kwarg-only in ma.dot now to start with?
If this turns out to be annoying somehow then go ahead with whatever
as far I'm concerned -- I don't want to hold up 1.10.2 by trying to
micro-optimize the transition path for an obscure corner of np.ma :-).
Nathaniel J. Smith -- http://vorpus.org
More information about the NumPy-Discussion