Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #49084 > unrolled thread
| Started by | jimjhb@aol.com |
|---|---|
| First post | 2013-06-24 16:51 -0400 |
| Last post | 2013-06-24 16:51 -0400 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Is this PEP-able? fwhile jimjhb@aol.com - 2013-06-24 16:51 -0400
| From | jimjhb@aol.com |
|---|---|
| Date | 2013-06-24 16:51 -0400 |
| Subject | Re: Is this PEP-able? fwhile |
| Message-ID | <mailman.3769.1372107444.3114.python-list@python.org> |
[Multipart message — attachments visible in raw view] — view raw
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 possible 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 <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 after the > '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 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' at 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 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 valid > (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.
Back to top | Article view | comp.lang.python
csiph-web