[Numpy-discussion] fromiter

Tim Hochberg tim.hochberg at cox.net
Sat Jun 3 10:29:04 EDT 2006

Travis Oliphant wrote:

>Tim Hochberg wrote:
>>Some time ago some people, myself including, were making some noise 
>>about having 'array' iterate over iterable object producing ndarrays in 
>>a manner analogous to they way sequences are treated. I finally got 
>>around to looking at it seriously and once I came to the following three 
>>   1. All I really care about is the 1D case where dtype is specified.
>>      This case should be relatively easy to implement so that it's
>>      fast. Most other cases are not likely to be particularly faster
>>      than converting the iterators to lists at the Python level and
>>      then passing those lists to array.
>>   2. 'array' already has plenty of special cases. I'm reluctant to add
>>      more.
>>   3. Adding this to 'array' would be non-trivial. The more cases we
>>      tried to make fast, the more likely that some of the paths would
>>      be buggy. Regardless of how we did it though, some cases would be
>>      much slower than other, which would probably be suprising.
>Good job.   I just added a called fromiter for this very purpose.  Right 
>now, it's just a stub that calls list(obj) first and then array.  Your 
>code would be a perfect fit for it.  I think count could be optional, 
>though, to handle cases where the count can be determined from the object.
I'll look at that when I get back. There are two ways to approach this: 
one is to only allow to count to be optional in those cases that the 
original object supports either __len__ or __length_hint__. The 
advantage their is that it's easy and there's no chance of locking up 
the interpreter by passing an unbounded generator. The other way is to 
figure out the length based on the generator itself. The "natural" way 
to do this is to steal stuff from array.array. However, that doesn't 
export a C-level interface that I can tell (everything is declared 
static), so you'd be going through the interpreter, which would 
potentially be slow. I guess another approach would be to hijack 
PyArray_Resize and steal the resizing pattern from array.array. I'm not 
sure how well that would work though.

I'll look into it...


>We'll look forward to your check-in.
>Numpy-discussion mailing list
>Numpy-discussion at lists.sourceforge.net

More information about the NumPy-Discussion mailing list