On Sep 27, 2015 12:58 PM, "Antony Lee" <antony.lee@berkeley.edu> wrote:
>
> Hi all,
>
> The docstring of np.full indicates that the result of the dtype is `np.array(fill_value).dtype`, as long as the keyword argument `dtype` itself is not set.  This is actually not the case: the current implementation always returns a float array when `dtype` is not set, see e.g.
>
> In [1]: np.full(1, 1)
> Out[1]: array([ 1.])
>
> In [2]: np.full(1, None)
> Out[2]: array([ nan])
>
> In [3]: np.full(1, None).dtype
> Out[3]: dtype('float64')
>
> In [4]: np.array(None)
> Out[4]: array(None, dtype=object)
>
> The note about return value of the dtype was actually explicitly discussed in https://github.com/numpy/numpy/pull/2875 but the tests failed to cover the case where the `dtype` argument is not passed.
>
> We could either change the docstring to match the current behavior, or fix the behavior to match what the docstring says (my preference).  @njsmith mentioned in https://github.com/numpy/numpy/issues/6366 that this may be acceptable as a bug fix, as "it's a very new function so there probably aren't many people relying on it" (it was introduced in 1.8).
>
> I guess the options are:
> - Fix the behavior outright and squeeze this in 1.10 as a bugfix (my preference).
> - Emit a warning in 1.10, fix in 1.11.
> - Do nothing for 1.10, warn in 1.11, fix in 1.12 (at that point the argument of `np.full` being a very new function starts becoming invalid...).
> - Change the docstring.

If this had been caught last month, I'd be in favor of making the change in the 1.10 prereleases and seeing if it caused any problems. At this point I think it's too risky for the 1.10 cycle, because we're very near the final release so there's little chance to notice if this does cause problems.

Given that, my vote is for a FutureWarning in 1.10 and change it in 1.11 (assuming we don't get a chorus of complaints before then).

-n