On Wed, Dec 10, 2014 at 9:01 AM, Ian Kelly wrote:
> This also seems perfectly natural:
>
> def len(iterable):
> return sum(1 for item in iterable)
>
> My observation is that seems strange to me that one standard sequence
operation should be supported for arbitrary iterators and the other not.
On Wed, Dec 10, 2014 at 1:21 AM, Peter Otten <__pete...@web.de> wrote:
>
> Ian Kelly wrote:
> > Huh, I wasn't even aware that membership tests worked on iterables with
no
> > __contains__ method. Seems odd to me that 'x in y' should be supported
but
> > not 'len(y)'.
>
> To me
>
> def contains(iter
Shiyao Ma wrote:
> Thanks guys.
>
> I was only aware of a limited iterables which themselves are iterators,
> e.g., the generator.
>
> Seems like its really a pitfall. Any glossary, list on the iterables that
> *might* exhaust themselves?
Iterables include:
- iterators
- sequences (e.g. lists,
Shiyao Ma wrote:
> Thanks guys.
>
> I was only aware of a limited iterables which themselves are iterators,
> e.g., the generator.
>
> Seems like its really a pitfall. Any glossary, list on the iterables that
> *might* exhaust themselves?
Usually the test
iterable is iter(iterable)
returns Tr
Thanks guys.
I was only aware of a limited iterables which themselves are iterators, e.g.,
the generator.
Seems like its really a pitfall. Any glossary, list on the iterables that
*might* exhaust themselves?
Regards.
--
https://mail.python.org/mailman/listinfo/python-list
Ian Kelly wrote:
> On Tue, Dec 9, 2014 at 11:30 PM, Chris Angelico wrote:
>> Are you sure it isn't? Your 'space' is an iterable cubic
>> cross-product. Your first loop checks (0,0,0) which is the first
>> element returned, and is thus fast... but it also *consumes* that
>> first element. The next
On Wed, 10 Dec 2014 17:53:05 +1100, Chris Angelico wrote:
> On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano
> wrote:
>> It would be nice if product iterators behaved like xrange() objects and
>> could perform "in" tests without exhausting the iterator, but they
>> don't. That's sad.
>
> It'd be
On 12/10/2014 1:53 AM, Chris Angelico wrote:
On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano wrote:
It would be nice if product iterators behaved like xrange() objects and
could perform "in" tests without exhausting the iterator, but they don't.
That's sad.
It'd be very difficult to do that
On Tue, Dec 9, 2014 at 11:30 PM, Chris Angelico wrote:
> Are you sure it isn't? Your 'space' is an iterable cubic
> cross-product. Your first loop checks (0,0,0) which is the first
> element returned, and is thus fast... but it also *consumes* that
> first element. The next time you test it, the e
On Wed, Dec 10, 2014 at 5:44 PM, Steven D'Aprano wrote:
> It would be nice if product iterators behaved like xrange() objects and
> could perform "in" tests without exhausting the iterator, but they don't.
> That's sad.
It'd be very difficult to do that in the general sense. But it should
be poss
On Wed, 10 Dec 2014 13:20:25 +0800, Shiyao Ma wrote:
> When doing nested loop, the very first iteration of the innermost loop
> ends ultimately slow.
>
> Let's the code speak.
>
> The following code is quite contrived. Actually it's derived from my
> 3d-dct script. The actual difference is way m
On Wed, Dec 10, 2014 at 4:20 PM, Shiyao Ma wrote:
> from itertools import product
> space_len = 580
> space = product(xrange(space_len), xrange(space_len), xrange(space_len))
>
> sparse_cloud = product(xrange(1000), xrange(1000), xrange(1000))
> for i, j, k in sparse_cloud:
> ts = timeit.defau
One thing to note, the logic of using "in" is not of concern here.
This is a *contrived* example, the problem is the slowness of the first
iteration.
--
https://mail.python.org/mailman/listinfo/python-list
When doing nested loop, the very first iteration of the innermost loop ends
ultimately slow.
Let's the code speak.
The following code is quite contrived. Actually it's derived from my 3d-dct
script.
The actual difference is way more significant than this example.
In case of any evil of gmail,
14 matches
Mail list logo
