np.full(..., dtype=structured-dtype) does not work as expected

[anntzer]

One would expect that np.full(shape, fill, dtype) works as t = np.empty(shape, dtype); t[:] = fill; return t but...

Reproducing code example:

the following works

In [3]: t = np.empty(10, [("a", int), ("b", float)])                                                                

In [4]: t[:] = (0, np.nan)                                                                                          

In [5]: t                                                                                                           
Out[5]: 
numpy.ndarray(
    [(0, nan), (0, nan), (0, nan), (0, nan), (0, nan), (0, nan), (0, nan),
     (0, nan), (0, nan), (0, nan)], dtype=[('a', '<i8'), ('b', '<f8')])

but the following doesn't

In [1]: np.full(10, (0, np.nan), [("a", int), ("b", float)])                                                        
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-1-b4402a777ba5> in <module>
----> 1 np.full(10, (0, np.nan), [("a", int), ("b", float)])

~/.local/lib/python3.7/site-packages/numpy/core/numeric.py in full(shape, fill_value, dtype, order)
    334         dtype = array(fill_value).dtype
    335     a = empty(shape, dtype, order)
--> 336     multiarray.copyto(a, fill_value, casting='unsafe')
    337     return a
    338 

ValueError: could not broadcast input array from shape (2) into shape (10)

As a side effect, even if it was decided that the above was not supported, the following certainly gives a wrong result:

In [9]: np.full(2, (0, np.nan), [("a", int), ("b", float)])                                                         
Out[9]: 
numpy.ndarray(
    [(                   0,  0.), (-9223372036854775808, nan)],
    dtype=[('a', '<i8'), ('b', '<f8')]
)

Numpy/Python version information:

1.16.3 3.7.3 (default, Mar 27 2019, 22:11:17) 
[GCC 7.3.0]

[oribro]

Well, by reading the numpy.full docs I infer that the fill value should be a scalar, a number,
while here we see a use of tuple as the 2nd fill argument.
I agree with @anntzer that the behaviour here is quite random.

Should we print an error for every non-scalar fill value? Or just trace special cases like the one above and handle them individually?
Edit: Is it possible to change the fill value definition to support any data type?

[seberg]

Seems like an obvious bug. Was there a reason why we are not using res.fill() in np.full0/np.full_like? It feels like there may have been, but also that it should solve this issue.

[mhvk]

Or indeed just do res[...] = fill_value, which, like @anntzer, I would have expected to happen (and in a completely separate thread, I noted that this equally fast - cannot find it anymore though!)

[seberg]

Fair point. I suppose the only difference is that fill and indexing will coerce to array with the new dtype, while copyto coerces to an array first.

The other question would be if we should change the copyto behaviour then...

EDIT: OK, fill is a bit a different possibly, since it goes to a specific scalar assignment path, but I wouldn't be surprised that in the end it just means the same thing.