while (a=b()) ...

[Jim Meier]

Tim Peters wrote:

> [Tim]
> > instead, or do
> >
> >     perpetuity = xrange(sys.maxint)
> >     ...
> >     for i in perpetuity:
>
> [Jim Meier]
> > Well, I kinda gawk at that. My gut says "ick!" because of the idea of
> > iterating over infinity.. "for" in python can often be synonymous with
> > "for each",  so "for each in in perpetuity" is meaningless.. perpetuity is
> > not a list or a set! Other than that, I think it's very neat.. how about
> > an
> > >>>in perpetuity:
> > ...    (stuff that is actually never intended to terminate)
>
> Jim, you may have missed that the above was not a proposal -- it works
> today.  "perpetuity" is indeed not a list or set, but it is a sequence, and
> sequences are what "for" chews on:
>

[snip the proof]

I understand that, but believe my point is still valid.

>
> For all the rest, it's been debated repeatedly over most of the 90's.  That
> doesn't mean it shouldn't be debated again, but it does mean a number of
> people who sat thru the last 10 iterations are likely to play with
> diminished enthusiasm this time around <wink>.
>
> > ...
> > So, for a "for each" to be meaningful, we need a. sequences(or generators)
> > to iterate over, and cursors to represent the current value of the
> > iteration.
>
> The latter is what Python lacks today, and the source of the frequent
>
>     for i in range(len(seq)):
>         element = seq[i]
>
> idiom.
>

Aha! I see now... the * is intended to be the guarauneed-sequential number of
the current iteration, then? I sympathise with the yearning, but my dislike is
increased by the (to me, anyways) non-intuitive feel of it. Does anyone use
(untested):
#defined somewhere global
def iterate(seq):
    return apply(lambda x,y: (seq(x), x), range(len(seq)))

#where you need to iterate with index
for (index,item) in iterate(sequence):
    print "item %i: %s" % (index, sequence)

?

It doesn't work with non-list things, but could probably easily be made to. I
was wondering if it was common to use a wrapper, both in this situation and in
others.

[snip]

> > Although I would try to make it more "pythonic" in my mind by
> > expressing it as
> > >    for (x,y) in (xlist, ylist):
> > >        print print "I'm printed min(len(x), len(y)) times."
> >
> > , although that's a little less legible.
>
> But already has a different meaning:
>
> >>> for (x, y) in ("ab", "cd"):
>         print x, y
>
> a b
> c d
> >>>

Yep. Gotcha.


>
> > ...
> > ...? Or is that a non-problem?
>
> Most suggestions are indeed non-problems because they try to assign new
> semantics to syntax that already means something else; dead on arrival.
> Proposals don't try to overload semicolons and keywords because they think
> it's pretty <wink>.

Damned if you do, damned if you don't ... (Not really. Python is damn near
perfect for what I like to use it for.)

>
>
> BTW, I'm one of those not bothered by "while 1:".  With a little
> imagination, those who are can instead write e.g.
>
>     while "more input remains":
>         line = f.readline()
>         if not line:
>             break
>         process(line)
>
> "more input remains" as eternally true as 1 is <wink>.
>
> never-met-a-loop-he-didn't-like-ly y'rs  - tim

I'm not really bothered by it either (all systems are abused for personal use,
no matter what the domain), and quite used to it as I used to do a lot of coding
in BASIC, and a fair bit of C. However, my main, big, current interest in Python
is it's readability and easy teachability to new users who have never programmed
before. I'm trying to make programming a nearly integral part of using my
project (a simulation-style game). So I'm looking for the most immediately
readable solutions, so that the skittish-but-ready aren't scared off.

-Jim.