Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #82290

Re: Nested loops is strangely slow, totally at a loss.

References <20141210052025.GA84184@FuzzyHorror> <CAPTjJmrM_nrGhPn2Le7b0iDOL5V035SOE3kVg98_89dVjueynA@mail.gmail.com> <CALwzid=vEcxcyxSN+8jXgC0VNKFBKNz5vZF+MrD7maGh0ECGAg@mail.gmail.com> <m68vqn$74v$1@ger.gmane.org>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2014-12-10 09:01 -0700
Subject Re: Nested loops is strangely slow, totally at a loss.
Newsgroups comp.lang.python
Message-ID <mailman.16811.1418227310.18130.python-list@python.org> (permalink)

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Wed, Dec 10, 2014 at 1:21 AM, Peter Otten <__peter__@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(iterable, value):
>     for item in iterable:
>         if item == value:
>             return True
>     return False
>
> seems to be a perfectly natural default behaviour. I don't see why
>
> >>> 42 in itertools.count()
> True
>
> should require that len(count()) must succeed.

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.

If the objection about `len(count())` is that the call would never return,
I'll point out that `-42 in count()` suffers the same problem.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Nested loops is strangely slow, totally at a loss. Ian Kelly <ian.g.kelly@gmail.com> - 2014-12-10 09:01 -0700

csiph-web