On Tue, Jan 31, 2012 at 15:35, Benjamin Root <ben.root@ou.edu> wrote:
>
>
> On Tue, Jan 31, 2012 at 9:18 AM, Robert Kern <robert.kern@gmail.com> wrote:
>>
>> On Tue, Jan 31, 2012 at 15:13, Benjamin Root <ben.root@ou.edu> wrote:
>>
>> > Is np.all() using np.array() or np.asanyarray()? If the latter, I would
>> > expect it to return a numpy array from a generator.
>>
>> Why would you expect that?
>>
>> [~/scratch]
>> |37> np.asanyarray(i>5 for i in range(10))
>> array(<generator object <genexpr> at 0xdc24a08>, dtype=object)
>>
>> --
>> Robert Kern
>
>
> What possible use-case could there be for a numpy array of generators?

Not many. This isn't an intentional feature, just a logical
consequence of all of the other intentional features being applied
consistently.

> Furthermore, from the documentation:
>
> numpy.asanyarray = asanyarray(a, dtype=None, order=None, maskna=None,
> ownmaskna=False)
>      Convert the input to an ndarray, but pass ndarray subclasses through.
>
>      Parameters
>      ----------
>      a : array_like
>          Input data, in any form that can be converted to an array. This
>          includes scalars, lists, lists of tuples, tuples, tuples of tuples,
>          tuples of lists, and ndarrays.
>
> Emphasis mine. A generator is an input that could be converted into an
> array. (Setting aside the issue of non-terminating generators such as those
> from cycle()).

I'm sorry, but this is not true. In general, it's too hard to do all
of the magic autodetermination that asarray() and array() do when
faced with an indeterminate-length iterable. We tried. That's why we
have fromiter(). By restricting the domain to an iterable yielding
scalars and requiring that the user specify the desired dtype,
fromiter() can figure out the rest.

Like it or not, "array_like" is practically defined by the behavior of
np.asarray(), not vice-versa.

In that case I agree with whoever said ealier it would be best to detect this case and throw an exception, as it'll probably save some headaches.

-=- Olivier