Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!news2.euro.net!novso.com!news.skynet.be!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.054 X-Spam-Evidence: '*H*': 0.89; '*S*': 0.00; '(at': 0.04; 'syntax': 0.04; 'python)': 0.05; 'indexing': 0.07; 'subject:PEP': 0.07; 'welcome.': 0.07; 'badly': 0.09; 'check,': 0.09; 'says.': 0.09; 'cc:addr:python-list': 0.11; 'email addr:python.org>': 0.11; 'python': 0.11; "'break'": 0.16; "'for',": 0.16; '(note:': 0.16; '24,': 0.16; 'itertools': 0.16; 'lambda': 0.16; 'true:': 0.16; 'language': 0.16; 'wrote:': 0.18; 'message-----': 0.19; 'possible,': 0.19; 'practices,': 0.19; '(the': 0.22; 'email addr:gmail.com>': 0.22; 'portion': 0.22; 'cc:addr:python.org': 0.22; 'accommodate': 0.24; 'effort.': 0.24; "shouldn't": 0.24; 'mon,': 0.24; 'cc:2**0': 0.24; 'cc:no real name:2**0': 0.24; '>': 0.26; 'least': 0.26; 'header:In-Reply-To:1': 0.27; "doesn't": 0.30; 'said,': 0.30; "i'm": 0.30; 'gives': 0.31; 'code': 0.31; 'comments': 0.31; 'argue': 0.31; 'motivation': 0.31; 'themselves': 0.32; 'run': 0.32; 'sense': 0.34; 'could': 0.34; 'agree': 0.35; 'convert': 0.35; 'etc.)': 0.35; 'but': 0.35; 'add': 0.35; 'there': 0.35; 'much.': 0.36; 'skip:f 40': 0.36; 'charset :us-ascii': 0.36; 'possible': 0.36; 'wrong': 0.37; 'too': 0.37; 'being': 0.38; 'skip:- 10': 0.38; 'subject:': 0.39; 'aspects': 0.39; 'bad': 0.39; 'itself': 0.39; 'sure': 0.39; 'even': 0.60; 'expression': 0.60; 'ian': 0.60; 'subject:? ': 0.60; 'from:no real name:2**0': 0.61; 'affect': 0.61; 'break': 0.61; 'course': 0.61; 'making': 0.63; 'header:Message-Id:1': 0.63; 'act': 0.63; 'name': 0.63; 're:': 0.63; 'real': 0.63; 'teaching': 0.64; 'more': 0.64; 'great': 0.65; 'to:addr:gmail.com': 0.65; 'overall': 0.69; 'as:': 0.81; 'subject:this': 0.83; "'and'": 0.84; "'for'": 0.84; 'adopting': 0.84; 'cater': 0.84; 'concept.': 0.84; 'for!': 0.84; 'improvement': 0.84; 'overall,': 0.84; 'received:172.29.51.140': 0.84; 'received:64.12.224': 0.84; 'received:mtaomg- da04.r1000.mx.aol.com': 0.84; 'costs,': 0.91; 'taught': 0.96; '2013': 0.98 References: <8D03F2B8CF0E7BE-1864-1796B@webmail-m103.sysops.aol.com> To: joshua.landau.ws@gmail.com Subject: Re: Is this PEP-able? fwhile In-Reply-To: X-MB-Message-Source: WebUI MIME-Version: 1.0 From: jimjhb@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D03F33BDE9399D_1864_58865_webmail-m103.sysops.aol.com" X-Mailer: AOL Webmail 37834-STANDARD X-Originating-IP: [208.67.228.35] Date: Mon, 24 Jun 2013 16:51:32 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1372107092; bh=rPbhvDI9IT8i7La910dRXH4KIHFPtDQNatXFQZdTP34=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=t/LxeyNO1AybflBx7/+o12XOwqr8D60kPDQcSrE5pstfcNwnEzcwPKl334bIBw7oX eXkME92i5xOULK5pbpXtblVUJcUl0bnzfKcrrgN0JTnYD3vWpO0rFWwjTK8dQpZy9z goiW/ycJytPV+eJw5Jj2i6OAfHRQw/Q2tUU665Gg= X-AOL-SCOLL-SCORE: 0:2:433800960:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338c51c8b15404f3 Cc: python-list@python.org 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: 200 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1372107444 news.xs4all.nl 15894 [2001:888:2000:d::a6]:44417 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:49084 This is a multi-part message in MIME format. ----------MB_8D03F33BDE9399D_1864_58865_webmail-m103.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I find itertools clumsy and wordy. You shouldn't have to have a lambda exp= ression just to break out of a for! I agree to not cater to bad practices, but if a clean improvement is possib= le it will practically help code overall, even if theoretically people shouldn't be adopting a practice (don= 't use breaks) to the wrong circumstance (the python 'for' is not like other fors in other languages). -Jim -----Original Message----- From: Joshua Landau To: jimjhb Cc: python-list Sent: Mon, Jun 24, 2013 4:41 pm Subject: Re: Is this PEP-able? fwhile On 24 June 2013 20:52, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after t= he > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from t= he > 'for'. There is one good reason not to use breaks: itertools. I often prefer a for-over-a-properly-constrained-iterable to a for-with-a-break, but there's no real reason to ever prefer a while. That said, why add this to the syntax when there's already functionality that gives you what you want? Just use itertools.takewhile as Ian Kelly says. > (NOTE: Many people are being taught to avoid 'break' and 'continue' at a= ll > costs, so they instead convert > the clean 'for' into a less-clean 'while'. Or they just let the 'for' ru= n > out. You can argue against this teaching > (at least for Python) but that doesn't mean it's not prevalent and > prevailing.) We shouldn't make a language around "people are taught the language badly - let us accommodate for their bad practices!" > [People who avoid the 'break' by functionalizing an inner portion of the > loop are just kidding themselves and making > their own code worse, IMO.] > > I'm not super familiar with CPython, but I'm pretty sure I could get this= up > and working without too much effort. > The mandatory 'and' makes sense because 'or' would hold the end value val= id > (weird) and not accomplish much. > The condition itself could of course have multiple parts to it, including > 'or's. > > It's possible the name 'fwhile' is not optimal, but that shouldn't affect > the overall merit/non-merit of the concept. "Possible"? It's more than just possible, *wink*. > Comments and Questions welcome. =20 ----------MB_8D03F33BDE9399D_1864_58865_webmail-m103.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I find itertools clumsy and= wordy.  You shouldn't have to have a lambda expression just to break = out of a for!

I agree to not cater to bad practices, but if a clean improvement is possib= le it will practically help code
overall, even if theoretically people shouldn't be adopting a practice= (don't use breaks) to the wrong
circumstance (the python 'for' is not like other fors in other languag= es).

-Jim


-----= Original Message-----
From: Joshua Landau <joshua.landau.ws@gmail.com>
To: jimjhb <jimjhb@aol.com>
Cc: python-list <python-list@python.org>
Sent: Mon, Jun 24, 2013 4:41 pm
Subject: Re: Is this PEP-able? fwhile

On 24 June 2013 20:52,  <jimjhb@aol.com> wrote:
> Syntax:
>
> fwhile X in ListY and conditionZ:
>
> The following would actually exactly as:  for X in ListY:
>
> fwhile X in ListY and True:
>
> fwhile would act much like 'for', but would stop if the condition afte=
r the
> 'and' is no longer True.
>
> The motivation is to be able to make use of all the great aspects of t=
he
> python 'for' (no indexing or explict
> end condition check, etc.) and at the same time avoiding a 'break' fro=
m the
> 'for'.

There is one good reason not to use breaks: itertools.
I often prefer a for-over-a-properly-constrained-iterable to a
for-with-a-break, but there's no real reason to ever prefer a while.

That said, why add this to the syntax when there's already
functionality that gives you what you want? Just use
itertools.takewhile as Ian Kelly says.

> (NOTE:  Many people are being taught to avoid 'break' and 'continue' a=
t all
> costs, so they instead convert
> the clean 'for' into a less-clean 'while'.  Or they just let the 'for'=
 run
> out.  You can argue against this teaching
> (at least for Python) but that doesn't mean it's not prevalent and
> prevailing.)

We shouldn't make a language around "people are taught the language
badly - let us accommodate for their bad practices!"

> [People who avoid the 'break' by functionalizing an inner portion of t=
he
> loop are just kidding themselves and making
> their own code worse, IMO.]
>
> I'm not super familiar with CPython, but I'm pretty sure I could get t=
his up
> and working without too much effort.
> The mandatory 'and' makes sense because 'or' would hold the end value =
valid
> (weird) and not accomplish much.
> The condition itself could of course have multiple parts to it, includ=
ing
> 'or's.
>
> It's possible the name 'fwhile' is not optimal, but that shouldn't aff=
ect
> the overall merit/non-merit of the concept.

"Possible"? It's more than just possible, *wink*.

> Comments and Questions welcome.
----------MB_8D03F33BDE9399D_1864_58865_webmail-m103.sysops.aol.com--