Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.005 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'method.': 0.07; 'odd': 0.07; 'skip:` 10': 0.07; 'observation': 0.09; 'def': 0.12; 'behaviour.': 0.16; 'iterable)': 0.16; 'iterable:': 0.16; 'iterables': 0.16; 'iterators': 0.16; 'objection': 0.16; 'return,': 0.16; 'subject:slow': 0.16; 'wrote:': 0.18; 'wed,': 0.18; 'seems': 0.21; '>>>': 0.22; 'tests': 0.22; '>>>': 0.24; '>': 0.26; 'supported': 0.26; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'am,': 0.29; 'dec': 0.30; 'message- id:@mail.gmail.com': 0.30; 'membership': 0.31; 'worked': 0.33; 'not.': 0.33; 'problem.': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'false': 0.36; 'sequence': 0.36; "i'll": 0.36; 'should': 0.36; 'to:addr:python-list': 0.38; 'to:addr:python.org': 0.39; 'even': 0.60; 'ian': 0.60; 'natural': 0.68; 'default': 0.69; 'otten': 0.84; 'succeed.': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=TYravCMAhzJwqZ2mMIOP4bBeITkFfXPpMRiS0x0exS4=; b=ZlZCawBBodDPEL43UGdgfDsppd9P1z6GHQeUWCRsNApf5fRCBSu9sSKc7PwBPiaE+I LtsU7QK3MxLJTA8a5NeJsKy2Fv72SJvYPm8yOjAOAkfyazIPOt5Q4s5zlVmZBxlQIZjP 4//8TS2gEeBRohCg18KGaM+IW7+WVrXmxDFT1JbofM7gFg+bu7vsRcP4twh9mMHXuR9S sUNXxZV0KMhUom8/7vbYG/IZWAeKrlDd7ja99Bc7rJn5FLf3FbXRkDr9DWRFuhOogVHA L31N0bL4BRoud+6y9V3Ujuo2cuj5uSexpa4CnNKvJvUJ7DPWVhBjofDTL7FGSIiMwj1Q +ZTg== X-Received: by 10.66.182.130 with SMTP id ee2mr8648183pac.22.1418227300550; Wed, 10 Dec 2014 08:01:40 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20141210052025.GA84184@FuzzyHorror> From: Ian Kelly Date: Wed, 10 Dec 2014 09:01:00 -0700 Subject: Re: Nested loops is strangely slow, totally at a loss. To: Python Content-Type: multipart/alternative; boundary=047d7bd6bb0075d1630509dec67f X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 63 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1418227310 news.xs4all.nl 2962 [2001:888:2000:d::a6]:41983 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:82290 --047d7bd6bb0075d1630509dec67f Content-Type: text/plain; charset=UTF-8 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. --047d7bd6bb0075d1630509dec67f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 10, 2014 at 1:21 AM, Peter Otten <__peter__@web.de> wrote:
>
> Ia= n Kelly wrote:
> > Huh, I wasn't even aware that membership te= sts 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, v= alue):
> =C2=A0 =C2=A0 for item in iterable:
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 if item =3D=3D value:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 return True
> =C2=A0 =C2=A0 return False
>
> s= eems to be a perfectly natural default behaviour. I don't see why
&g= t;
> >>> 42 in itertools.count()
> True
>
>= ; should require that len(count()) must succeed.

This also seem= s perfectly natural:

def len(iterable):
= =C2=A0 =C2=A0 return sum(1 for item in iterable)

M= y observation is that seems strange to me that one standard sequence operat= ion should be supported for arbitrary iterators and the other not.

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