RFC: Assignment in Conditional
Sean Reifschneider
that when someone asks about why they can't do "if line = fp.readline():".
However, it seems fairly clear that this restriction results in kludges
like:
while 1:
line = fp.readline()
if not line: break
print line
In a language which is touted as being so clear, I'm kind of surprised that
this hasn't received more attention.
It would seem that one could set up a variable or possibly a set of variables
which would contain the value of the expression in the last executed
conditional:
while fp.readline():
if re.match(whileVar, r'^\s*(\S+)\s*=\s*(\S+)\s*$'):
print 'Assignment "%s" = "%s"' % ( ifVar.group(1), ifVar.group(2) )
This has the benefit of allowing you to easily see the termination condition
for the while loop, instead of assuming it's infinite until you search
through (the possibly complex) body.
This would seem to eliminate the required kludge, while still keeping with the
basic spirit of Python. However, before going through and making a patch for
Python, I wanted to see what comments folks had on this idea.
The next logical step I could see would be adding a variant to conditionals:
while [ <word> = ] <expression>:
where if the optional [ <word> = ] part of the while statement were there it
would assign the expression value to <word> in addition to the whileVar. But
then what would be the point of having the whileVar?
Is the only concern that this will be confused with the "==" comparison
operator? In that case, would "while [ <word> assign_the_value_of ]
<expression>:" (or something similar) be more appropriate? Or perhaps
even something along the lines of "<word> = while <expression>:"?
That feels a bit strange, but surely won't be mistaken for a comparator...
The only issue I see with this is the scope of the "whileVar". Presumably
one could limit the scope by doing a "whileVar = None", or perhaps the
termination of a while would imply that?
Thanks,
Sean
--
I used to think that the brain was the most wonderful organ in
my body. Then I realized who was telling me this. -- Emo Phillips
Sean Reifschneider, Inimitably Superfluous <jafo...@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.
Michael Scharf
>
> We all realize that assignment isn't an operator. It's easy enough to chant
> that when someone asks about why they can't do "if line = fp.readline():".
> However, it seems fairly clear that this restriction results in kludges
> like:
>
> while 1:
> line = fp.readline()
> if not line: break
> print line
>
> In a language which is touted as being so clear, I'm kind of surprised that
> this hasn't received more attention.
This comes up every few month (search in dejanews for 'assignment expression'
and you'll find some answers).
http://www.dejanews.com/getdoc.xp?AN=160191343
http://www.dejanews.com/getdoc.xp?AN=421739003
http://www.dejanews.com/getdoc.xp?AN=421980085
Maybe something should go to the FAQ.
Michael
--
''''\ Michael Scharf
` c-@@ TakeFive Software
` > http://www.TakeFive.com
\_ V mailto:Michael...@TakeFive.co.at
Christian Tismer
>
> We all realize that assignment isn't an operator. It's easy enough to chant
> that when someone asks about why they can't do "if line = fp.readline():".
> However, it seems fairly clear that this restriction results in kludges
> like:
>
> while 1:
> line = fp.readline()
> if not line: break
> print line
>
> In a language which is touted as being so clear, I'm kind of surprised that
> this hasn't received more attention.
It has. You can do the assignment inside a class instance and
iterate over this. Guido did this in a very elegant way.
Try this:
import fileinput
for line in fileinput.input():
process(line)
It doesn't read the whole bunch but behaves like a sequence
and enumerates all the input lines by its __getitem__ method.
If you think you must, here is also a minimal example
how to wrap an assignment by a small class.
class remember:
def __init__(self, func):
self.func = func
def __call__(self):
self.line = self.func()
return self.line
myline = remember(open('c:\\autoexec.bat').readline)
while myline():
print myline.line
All in all it is no big deal and not necessary.
cao - chris
--
Christian Tismer :^) <mailto:tis...@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgp.ai.mit.edu/
we're tired of banana software - shipped green, ripens at home
Sean Reifschneider
Christian Tismer <tis...@appliedbiometrics.com> wrote:
>It has. You can do the assignment inside a class instance and
>iterate over this. Guido did this in a very elegant way.
With all due respect, if it's so elegant why does Guido recommend not
using it for performance reasons? Search DejaNews if you're really
interested.
> import fileinput
> for line in fileinput.input():
> process(line)
This is one of the few places in the library where you can do something
similar to the above. If you don't care about performance, you can also
do:
for line in sys.stdin.readlines():
process(line)
so why do you need fileinput at all?
The point is that fileinput is the only place you get that nice syntax
(what if I'm reading data from sockets or pipes?). My proposal above
removes the need for kludges such as building classes so you can use
__getitem__.
>If you think you must, here is also a minimal example
>how to wrap an assignment by a small class.
[Example replacing 3 lines of code with 9 deleted]
>All in all it is no big deal and not necessary.
Perhaps so... One could make the same argument for a number of features
which have been added to Python (lambda, map, filter, multiple assignment
which may even tend to promote these discussions). Yet amazingly this
issue continues to be brought up...
Sean
--
Jackie Trehorn treats objects like women, man...
-- _The_Big_Lebowski_
Sean Reifschneider
Michael Scharf <Michael...@gmx.de> wrote:
>This comes up every few month (search in dejanews for 'assignment expression'
>and you'll find some answers).
At the risk of being monotonous, I'd like to repeat the first two lines of my
original post:
>We all realize that assignment isn't an operator. It's easy enough to chant
>that when someone asks about why they can't do "if line = fp.readline():".
What could I have done to make it more clear that I was talking about
changing the syntax for conditionals, *NOT* turning assignment into
an expression?
Sean
--
A smart terminal is not a smart*ass* terminal, but rather a terminal
you can educate. -- Rob Pike
Tim Peters
> We all realize that assignment isn't an operator. It's easy
> enough to chant that when someone asks about why they can't do
"if line = fp.readline():".
> like:
>
> while 1:
> line = fp.readline()
> if not line: break
> print line
>
> In a language which is touted as being so clear, I'm kind of
> surprised that this hasn't received more attention.
It's received *enough* attention, though, that the very thought of replying
to yet another msg about it makes me a bit physically ill <0.7 wink>.
I've done more than my share of supplying stupid "workarounds", so I guess I
deserve that. In real life I always use the "kludge" you listed above.
> It would seem that one could set up a variable or possibly a set
> of variables which would contain the value of the expression in the
> last executed conditional:
>
> while fp.readline():
> if re.match(whileVar, r'^\s*(\S+)\s*=\s*(\S+)\s*$'):
> print 'Assignment "%s" = "%s"' % ( ifVar.group(1),
> ifVar.group(2) )
> This has the benefit of allowing you to easily see the
> termination condition for the while loop, instead of assuming it's
> infinite until you search through (the possibly complex) body.
Actually, when I see
while 1:
I assume the opposite: that it's a finite loop and I'll find an "if ...:
break" one or two lines down. I'm rarely disappointed <wink>.
> This would seem to eliminate the required kludge, while still
> keeping with the basic spirit of Python. However, before going
> through and making a patch for Python, I wanted to see what comments
> folks had on this idea.
Frankly, I hate it. Vars with magic names that change bindings as a result
of magical side-effects sounds more Perlish than Pythonish to me. The only
thing Python has like that now is the one-character "_" as a convenience in
interactive mode.
Believe it or not, I *do* sympathize with your complaint -- while I'm used
to it now, I've never *liked* writing "while 1:" (for the very reasons you
state), and think it would be peachy to peel the conditional banana.
> The next logical step I could see would be adding a variant to
> conditionals:
>
> while [ <word> = ] <expression>:
>
> where if the optional [ <word> = ] part of the while statement
> were there it would assign the expression value to <word> in addition
> to the whileVar.
Ack, no -- this is almost certainly what Guido was trying to *avoid*, i.e.
the ridiculous subtle bugs that pop up in C from writing
while (x = f()) { ... }
by mistake when
while (x == f()) { ... }
was intended. God knows, just last week I tracked down what turned out to
be a
assert(n = 1);
bug in C++ (that assert is a self-fulfilling prophecy <snarl>).
Every post-C language except the no-choice-in-the-matter C++, and Perl (&
now Ruby too, alas), has moved heaven and earth to avoid propagating this
miserable design error.
> But then what would be the point of having the whileVar?
Absolutely none -- which is good <wink>. I've said before that I favor
while x := f():
i.e. use the currently-unused ":=" to mean binding-as-expression.
> Is the only concern that this will be confused with the "==" comparison
> operator?
It's a major concern, yes. Whether it's Guido's only concern "in theory" I
don't know. Based on his well-known fear of lexical scoping <wink>, he
could also harbor some terror about abuses like:
while (sum := (x := f()) + (y := g()) + (z := h())) < (lim := i()):
print "sum", sum, "<", lim, "prod", x*y*z
But I think the best way to encourage clean code is to ridicule newbie code
postied to c.l.py <wink>.
> In that case, would
> while [ <word> assign_the_value_of ] <expression>:
> (or something similar) be more appropriate?
Definitely, if it flies at all.
> Or perhaps even something along the lines of
> <word> = while <expression>:
>
> That feels a bit strange, but surely won't be mistaken for
> a comparator...
This appears to be an instance of the ever-popular yet never-successful
c.l.py meta-strategy that when you can't get Guido to adopt a reasonable
suggestion, try an insane one <0.98 wink>.
> The only issue I see with this is the scope of the "whileVar". Presumably
> one could limit the scope by doing a "whileVar = None", or perhaps the
> termination of a while would imply that?
while e1():
while e2():
# what does whileVar mean here -- e1 or e2? e2, I guess.
# any way to get at e1?
# what does whileVar mean *here*? None? or is there some magical
# stack of whileVars and the binding to e1 got restored when the
# inner while terminated?
if whileVar in ('End', 'Quit'):
break
# and now what? I can't get at the value that caused the loop to break?
All of those irksome questions (& many more) are sidestepped cleanly by
letting the user bind their own vars explicitly when & as they feel they
need to.
the-most-disagreeble-supporter-you're-likely-to-find<wink>-ly y'rs - tim
Andrew M. Kuchling
>[Sean Reifschneider]
>> We all realize that assignment isn't an operator. It's easy
>> enough to chant that when someone asks about why they can't do
> "if line = fp.readline():".
>> However, it seems fairly clear that this restriction results in kludges
>> like:
>>
>> while 1:
>> line = fp.readline()
>> if not line: break
>> print line
IMHO the problem isn't not being able to do assignments, or
get the result of some expression, inside a while. It's that Python
only has 'while', and no do..while:
do:
line = fp.readline()
while not line
This is one of my few problems with the language, and though I've
gotten used to writing 'while 1'...'if something: break', it still
gives me a twinge of annoyance every time I do it.
(Aside: didn't someone suggest generalizing do...while once by
allowing conditions inside the block? Can't pull it up in Dejanews,
though.)
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
>VERY cool mod, Peter. I'll be curious to see GvR's reaction to your
syntax.
Hm.
-- Nick Seidenman and Guido van Rossum, 1 Aug 1996
Guido van Rossum
alternate assignment operator, <-, which *is* allowed in expressions.
You could then write
while line <- fp.readline():
...process line...
I'm not sure I like it myself, but it would sure avoid the confusion
betwee = and ==, and I don't think that much confusion between < and
<- is likely.
Just a thought for the holidays,
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
> line = fp.readline()
> while not line
But what if you want to do more with the line? Algol-68 had something
like this:
do:
...some code...
while condition:
...more code...
(except they also combined it with the for loop in some way).
PS Andrew: I won't be in today; happy Holidays,
Ivan Van Laningham
Guido van Rossum wrote:
>
> Before I go, here's a potential way out. Perhaps there could be an
> alternate assignment operator, <-, which *is* allowed in expressions.
> You could then write
>
> while line <- fp.readline():
> ...process line...
>
> I'm not sure I like it myself, but it would sure avoid the confusion
> betwee = and ==, and I don't think that much confusion between < and
> <- is likely.
>
> Just a thought for the holidays,
>
Eeeeuuwww. Sorry. The devil made me say it. But I *much* prefer Uncle
Timmy's ``:='' operator.
<- is-to- := -as-slugs-are-to-snails-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
iva...@callware.com
http://www.pauahtun.org
----------------------------------------------
Hans Nowak
>Before I go, here's a potential way out. Perhaps there could be an
>alternate assignment operator, <-, which *is* allowed in expressions. You
>could then write
>
> while line <- fp.readline():
> ...process line...
Cool, but wouldn't that collide with code like
while x<-2:
do_something()
x = x - 1
?
In other words, isn't there ambiguity between "while x < -2" and "while x <-
2"? If so, how will it be resolved?
+ Zephyr Falcon | Storm Seeker | Hans Nowak
+ Homepage (under construction): http://www.cuci.nl/~hnowak/
+ You call me a masterless man. You are wrong. I am my own master.
+ May Grandma Moses cheat on your fiance with your cream and sour onion chips!
Tim Peters
> Before I go, here's a potential way out. Perhaps there could be an
> alternate assignment operator, <-, which *is* allowed in expressions.
> You could then write
>
> while line <- fp.readline():
> ...process line...
That's the one I keep suggesting, although I've spelled it := for backward
compatibility (e.g. "while i<-3:" already means something else; ":=" is
never legit now), and because that digraph does mean assignment in several
other languages Python would not be ashamed to eat dinner with. Note that
the colon here won't confuse pymode (or other simple but not braindead
regexp-based parsers) either.
> I'm not sure I like it myself, but it would sure avoid the confusion
> between = and ==, and I don't think that much confusion between < and
> <- is likely.
Trust me: you'll never *really* like it, because it opens a door to all
sorts of obfuscated abuse. But you *would* like it in tasteful code that
you and I write, and we can bully everyone else into playing nice too by
merciless public shaming of bad taste <wink>.
"if m := regexpobject(match):"-dreaming-ly y'rs - tim
jim....@mci.com
> The amazing Guido van Rossum wrote:
>
> >Before I go, here's a potential way out. Perhaps there could be an
> >alternate assignment operator, <-, which *is* allowed in expressions. You
> >could then write
> >
> > while line <- fp.readline():
> > ...process line...
>
> Cool, but wouldn't that collide with code like
>
> while x<-2:
> do_something()
> x = x - 1
> ?
>
> In other words, isn't there ambiguity between "while x < -2" and "while x <-
> 2"? If so, how will it be resolved?
Significance of whitespace--another mechanism courtesy of 'The Amazing Guido".
Christopher Tavares
Guido van Rossum wrote in message
<1998122414...@eric.cnri.reston.va.us>...
>> do:
>> line = fp.readline()
>> while not line
>
>But what if you want to do more with the line? Algol-68 had something
>like this:
>
> do:
> ...some code...
> while condition:
> ...more code...
>
>(except they also combined it with the for loop in some way).
I'm just a python nobody, but I have to say that I *REALLY*, *REALLY* like
this. It's completely general, easy to understand, and lets us avoid the
damn assignment morass. The only down side is the new keyword. Well, maybe
Python 1.6?
This is similar to something from my obscure computer languages collection.
Anyone out there remember Basic-09? This was a language that combined the
best of Basic and Pascal (kinda like VB combines the worst <G>). There was a
control structure there that worked like this:
do
.... some stuff ...
exitif condition
... stuff on exit ...
endexit
.... more stuff ....
loop
This worked very well in practice, although I never saw a real reason for
the ... stuff on exit ... section.
-Chris
Tim Peters
> IMHO the problem isn't not being able to do assignments, or
> get the result of some expression, inside a while. It's that Python
> only has 'while', and no do..while:
>
> line = fp.readline()
> while not line
I don't understand what you're suggesting there: like, where does the
*code* go? If it's after the "line =" but before the "while" as in C, it
would have to look like
do:
line = fp.readline()
if line:
code goes here
code goes here
code goes here
while not line
to do the same thing, and that's no improvement over
while 1:
line = fp.readline()
if not line:
break
code goes here
code goes here
code goes here
Or does the condition on the "while" magically get evaluated right after the
first stmt following the "do" is executed <wink/shiver>?
> This is one of my few problems with the language, and though I've
> gotten used to writing 'while 1'...'if something: break', it still
> gives me a twinge of annoyance every time I do it.
Same here.
> (Aside: didn't someone suggest generalizing do...while once by
> allowing conditions inside the block? Can't pull it up in Dejanews,
> though.)
Terry Reedy made a good pitch, in thread
Proposal: do-while-(do) (was [Q] Perl vs. Python)
from late June. I still recommend that people read Knuth's classic
"Structured Programming with Gotos" for a slew of creative approaches.
Assignment-as-expression is good for more than just exit-at-the-top loops,
though. It can be genuinely helpful whenever a function may return a
special-case value. Most frequently this year, I've dutifully replied to
msg after msg griping about:
m = re.search(re1, line)
if m:
xxx(m)
else:
m = re.search(re2, line)
if m:
yyy(m)
else:
m = re.search(e3, line)
if m:
zzz(m)
else:
poop()
etc. There are other ways to write this, but I twinge too at trotting them
out because there's really no way as simple or clear as the obvious thing
the complainer *wants* to do:
if m := re.search(re1, line):
xxx(m)
elif m := re.search(re2, line):
yyy(m)
elif m := re.search(re3, line):
zzz(m)
else:
poop()
I'd trade the reduction in artificial nesting (or clever convolution to
avoid it some other way) for the chance that some dribbler will abuse it:
def fac(n):
a=long(n or 1)
while(n:=n-1)>1 and a:=a*n:pass
return a
it-would-sure-make-obfuscated-python-contests-more-fun<wink>-ly y'rs - tim
Magnus L. Hetland
I'm a bit tired -- sorry if I ramble on a bit :)
"Christopher Tavares" <tav...@connix.com> writes:
> Guido van Rossum wrote in message
> <1998122414...@eric.cnri.reston.va.us>...
> >> do:
> >> line = fp.readline()
> >> while not line
(I guess that should be "while line"...)
> >
> >But what if you want to do more with the line? Algol-68 had something
> >like this:
> >
> > do:
> > ...some code...
> > while condition:
> > ...more code...
> >
Meaning...?
> >(except they also combined it with the for loop in some way).
(And the if/else, and the def and ... seems a bit convoluted. ;)
> I'm just a python nobody, but I have to say that I *REALLY*, *REALLY* like
> this. It's completely general, easy to understand,
Okay, call me stupid, but I don't think it's easy to understand. Does
it mean the same as:
while 1:
...some code...
if not condition: break
...more code...
? Actually I think this is clearer (although not as "pretty"). I
usually relate these control structures to natural language... This
latter thing means:
Until I tell you otherwise:
Do something
If some condition: Stop everything
Do something more
The thing above might be stated as:
Do something while some condition is true do something else.
What does that mean? It's not even a proper sentence...
Oh well...
> and lets us avoid the
> damn assignment morass.
Yes, it does... However, going from while to do--while is very simple.
do:
line = fp.readline()
print line
while line
is the same as
line = fp.readline()
while line:
print line
line = fp.readline()
Now this seems pretty clear to me. And if we wanted to have the
functionality of the do--while loop without sacrificing standard
Python syntax, how about using repeat--until without the "repeat"?
until not line:
line = fp.readline()
print line
(This executes the body once before checking the condition)
Or maybe it should be possible to do something like...
while line=fp.readline(); line:
print line
> The only down side is the new keyword. Well, maybe
> Python 1.6?
New keyword ... that sounds more like P2...
> do
> .... some stuff ...
> exitif condition
> ... stuff on exit ...
> endexit
> .... more stuff ....
> loop
Sounds cool enough... and quite similar to the standard "while 1: ...
if condition: break ..." thing. Almost identical, in fact :)
My professor Arne Halaas published an article on another control
structure in 1975, which is quite general. He called it "detect". It
works like this:
DETECT <event1> OR <event2> OR ... OR <eventn>
IN
...
NI
The events can be either constants or event-variables given some value
(I'm not quite clear on their function... ;)
The event constants are used in the loop like this:
<event3> {some code};
Thus if the event is detected by the surrounding DETECT-block, the
code in the {} part is executed and execution is resumed after the NI
part of the DETECT-block. Several events could be used, like in
<event1> OR <event2> {some code};
These indicator statements may be mixed with ordinary code (sorta like
break statements). In his article, Halaas uses the example of the
Quicksort Partition algorithm using what might be seen as two
coroutines moving element up and down:
(Array elements A(m)..A(n) are to be partitioned)
i := m-1; j := n;
v := A(n);
DETECT partition done
IN
DETECT downmovej
IN
i := i+1;
IF i=j THEN partition done;
IF A(i)>v THEN downmovej {A(j):=A(i);};
NI
DETECT upmovei
IN
j := j-1;
IF j=i THEN partition done;
IF A(j)<v THEN upmovei {A(i):=A(j);};
NI
NI
A(j):= v
A suitable Python syntax for this sort of thing might be (I'm changing
it a bit here, I guess -- removing the {}-part, making it necessary to
use if-statements. I think that would be clearer in Python...):
i = m-1
j = n
v = A[n]
detect "Partition_done":
detect "Move j down":
i = i+1
if i==j: break "Partition done"
if A[i] < v:
A[j] = A[i]
break "Move j down"
detect "Move i up":
j = j-1
if j==i: break "Partition done"
if A[j] < v:
A[i] = A[j]
break "Move i up"
A[j] = v
This looks quite like labelled breaks, I guess... (The use of strings
in the above is arbitrary -- one might easily have a separate label
type or something...)
One advantage of the detect structure (as Halaas points out) is that
the events may be used to make the code document itself quite nicely.
You clearly see why things are happening.
Now -- back to the original problem...
detect "End of file":
line = fp.readline()
if not line: break "End of line"
print line
I kind of like this approach (though I'm sure my syntax suggestions
leave a lot to be desired). In the simple example above, the labels
may not be very useful, but the partition example shows how they may
be. Anyway, even in this simple example, I think the mechanism looks
prettier than arbitrarily looping forever, and then later breaking
out... At least here you show what you are waiting for.
And if we *must* use the endless looping solution (without any labels)
can't we *please* have a separate keyword like "loop"? "while 1" seems
so arbitrary...
loop:
line = fp.readline()
if not line: break
print line
That isn't so bad, is it? (Of course it can't be nested -- but the
"detect" structure can...)
And lastly: Any errors or shortcomings in the detect-presentation
above are mine alone.
--
Magnus
Lie
Hetland www.pvv.org/arcadia <arc...@pvv.org>
Magnus L. Hetland
"Tim Peters" <tim...@email.msn.com> writes:
[...]
Just a thought -- what about a statement/expression-expression, like
(statement; ... statement; expression) returning the value of the
expression?
Then things like
while l = fp.readline():
print l
could be written
while (l = fp.readline(); l):
print l
I suggested this, without the parentheses in a former post, but that
was only for while loops and if sentences etc. A general construct
like this could be used anywhere... (I got the idea from the "Tiger"
language...)
>
> if m := re.search(re1, line):
> xxx(m)
> elif m := re.search(re2, line):
> yyy(m)
> elif m := re.search(re3, line):
> zzz(m)
> else:
> poop()
>
if (m = re.search(rel, line); m):
xxx(m)
.
.
.
Or alternatively:
if m=re.search(rel, line); m:
xxx(m)
.
.
.
Seems logical to me...
>
> def fac(n):
> a=long(n or 1)
> while(n:=n-1)>1 and a:=a*n:pass
> return a
>
def fac(n):
a=long(n or 1)
while (n=n-1;n)>1 and (a=a*n;a): pass
return a
Doesn't look *too* bad, does it? (Isn't this how the comma operator
works in C?)
Tim Peters
> ...
> My professor Arne Halaas published an article on another control
> structure in 1975, which is quite general. He called it "detect".
See Knuth's "Structured Programming with Gotos" for variants of this
approach; they were quite popular in the 70's, if not in actual languages at
least as a topic in unread papers <wink>.
> ...
> And if we *must* use the endless looping solution (without any labels)
> can't we *please* have a separate keyword like "loop"? "while 1" seems
> so arbitrary...
There's nothing magic about 1! You can (& I sometimes do) write stuff like:
while "fp has more stuff":
line = fp.readline()
if not line:
break
process(line)
This is a bit slower than "while 1:" today, but nothing a peephole optimizer
couldn't safely squash out of existence.
Similarly in C or C++ it's often better to write
assert(!"wow -- unto the root is born a brother!");
than
assert(0);
high-on-christmas-cashews-and-chocolate-ly y'rs - tim
scott cotton
This sounds wonderful, absolutely wonderful, except that I
agree that ':=' would be preferable. It'd force a bit of
reprogramming python-mode.el i would guess, though.
Some other operator ideas:
?= (i like this one...)
@= (hmmm.)
scott
On Thu, Dec 24, 1998 at 09:36:47AM -0500, Guido van Rossum wrote:
| Before I go, here's a potential way out. Perhaps there could be an
| alternate assignment operator, <-, which *is* allowed in expressions.
| You could then write
|
| while line <- fp.readline():
| ...process line...
|
| I'm not sure I like it myself, but it would sure avoid the confusion
| betwee = and ==, and I don't think that much confusion between < and
| <- is likely.
|
| Just a thought for the holidays,
|
Dirk Heise
> | Before I go, here's a potential way out. Perhaps there could be an
> | alternate assignment operator, <-, which *is* allowed in expressions.
> | You could then write
> |
> | while line <- fp.readline():
> | ...process line...
> |
> | I'm not sure I like it myself, but it would sure avoid the confusion
> | betwee = and ==, and I don't think that much confusion between < and
> | <- is likely.
while a <-4:
Have another go ;-)
Dirk
Evan Simpson
again put forward my own ugly little brainchild, to wit:
while =line= fp.readline():
#process line
Which, for those who haven't already seen it struck down in its youth, is
simply the extension of "x = y = z = 0" type notation into an expression via
the leading "=". It is illegal in current code, requires no additional
keywords or symbols, and absolutely cannot produce "="/"==" errors in sane
human beings (or Tims, I believe).
Failing that, ":=" is a fine alternative.
Guido van Rossum wrote in message
<1998122414...@eric.cnri.reston.va.us>...
Allen Ethridge
Guido van Rossum wrote:
> Before I go, here's a potential way out. Perhaps there could be an
> alternate assignment operator, <-, which *is* allowed in expressions.
> You could then write
> while line <- fp.readline():
> ...process line...
> I'm not sure I like it myself, but it would sure avoid the confusion
> betwee = and ==, and I don't think that much confusion between < and
> <- is likely.
> Just a thought for the holidays,
What about "->", as in
while fp.readline() -> line:
...process line...
It'd sure make me for more at home with Python. And it's really
quite pleasant once you get used to it. But I'm to new to Python
to come up with any "a->b" ambiguities.
Allen
Bjorn Pettersen
finger on it... until I typed:
def f(x):
return x
y = -20
while y<-f(5):
print y
bjornbjornbjornbjornbjorn...
Ivan Van Laningham wrote:
> Hi All, & Merry Christmas!
>
> Guido van Rossum wrote:
> >
> > Before I go, here's a potential way out. Perhaps there could be an
> > alternate assignment operator, <-, which *is* allowed in expressions.
> > You could then write
> >
> > while line <- fp.readline():
> > ...process line...
> >
> > I'm not sure I like it myself, but it would sure avoid the confusion
> > betwee = and ==, and I don't think that much confusion between < and
> > <- is likely.
> >
> > Just a thought for the holidays,
> >
>
jim....@mci.com
Sorry if this is a FAQ.
Looked in the mailing list since 12/7--no mention.
Looked in the FAQ--not there.
Searched in ftp site, website, SIG archives, Starship--not there.
I'm having difficulty installing Python on my NT Workstation box.
When I try to install, it says I must have admin rights and to log in as
admin to install.
I do have admin rights, but can't perform the installation as another user.
Couldn't we check for admin rights, rather than for login as admin?
I do not have (and won't get) the Admin login.
help!
TIA,
--jim
Magnus L. Hetland
> Guido van Rossum wrote:
[...]
>
> What about "->", as in
>
Good idea -- as opposed to <-... But I still don't *quite* see the
need for it. I do agree that more powerful control structures may be
desirable, but this is a very small addition, at the cost of new
syntax.
> while fp.readline() -> line:
> ...process line...
At the cost of writing the assignment once more, you can have this:
line = fp.readline()
while line:
...process line...
line = fp.readline()
This is quite clear and simple, in my opinion -- and it is general
too, as opposed to the "while x=spam():" thing. It can be used in
f.eks.
x = 1
while x < 10:
print x
x = x+1
Quite standard, and quite readable.
In the case of counting down, you could write
while x-1 -> x:
print x
I must say I find that less readable, although I admit it is more
succinct.
If what you need it for is primarily iterating throug lines in file
objects, why not use:
for line in fp.readlines():
...process line...
That is simpler than all of the above, IMHO.
And another idea.... How about a local variable "it", like in
HyperTalk and all its variations? I fondly remember writing:
get the square of 2
put it into x
We could have something like:
while fp.readline():
print it
Or
while fp.readline():
line = it
...process line...
This could be used in other structures too...
if contents: process(it)
I mean -- that's the problem here, isn't it? Retaining the value of
the fp.readline() after the check? (To solve that, one might of course
make fp the instance of an iteration class which has a separate method
for checking...
while fp.has_more_lines():
print fp.readline()
)
A-bit-tired-with-my-brain-all-over'ly yrs
Magnus L. Hetland
How about another keyword like "indexing"?
while line updated line=fp.readline():
print line
Maybe even
for line updated line=fp.readline():
print line
That is -- "for all the lines in the sequence created by the update
'line=fp.readline()'". When the updated variable is None, the sequence
has ended... (Of cours, one could not use "false" as an ending
condition here, or you could not iterate over boolean information etc.)
Oh, well -- it was just a thought.
jim....@mci.com
Gordon McMillan
> I'm having difficulty installing Python on my NT Workstation box.
>
> When I try to install, it says I must have admin rights and to log
> in as admin to install.
>
> I do have admin rights, but can't perform the installation as
> another user.
>
> Couldn't we check for admin rights, rather than for login as admin?
>
> I do not have (and won't get) the Admin login.
I think it is checking rights, not the login (since I do it under my
login). I doubt you really have full admin rights. I suspect the
right in question is to modify the HKEY_LOCAL_MACHINE section of the
registry.
- Gordon
Bjorn Pettersen
line = fp.readline()
while line:
...
line = fp.readline()
is if you have to do other things before you assign to line (you'll then
need to keep your code in sync). Which leads to the ugly while 1
idiom....
Using
for line in fp.readlines():
...
would work great, except it's quite a strain when the file length
approches 1Gb (actually a long time before that, but you get my point...)
It is also not general.
Check out the other threads on this topic for lots of reasons why people
need this feature.
-- bjorn
Christopher G. Petrilli
> line = fp.readline()
> while line:
> ...
> line = fp.readline()
> is if you have to do other things before you assign to line (you'll then
> need to keep your code in sync). Which leads to the ugly while 1
> idiom....
It's not "perfect" but I regularly process files that are several
hundered megabytes with Python (building data-structures in memory that
are 50-100Mb each) without any problem with this. If this is something
I have to suffer with because any solution is a kludge, then I'll live
with it.
> Using
> for line in fp.readlines():
> ...
> would work great, except it's quite a strain when the file length
> approches 1Gb (actually a long time before that, but you get my point...)
> It is also not general.
Have you checked out the fileinput module? This works great for a lot
of things.
> Check out the other threads on this topic for lots of reasons why people
> need this feature.
Always be careful of the implied differences between need and WANT. I
want a lot of things, I haven't found a single thing in 3 years in
Python that I absolutely NEED to be added because it's fatal without it.
ALl languages have idioms.
Chris
--
| Christopher Petrilli
| petr...@amber.org
Evan Simpson
changed my mind. I'll tell you why.
1. There is exactly one place where this sort of notation would be useful:
the condition expression of a while loop. In every other case, performing
the name binding first as a separate statement imposes no real penalty.
2. It's very easy to learn to see "while 1:" as "loop:". The actual problem
with this sort of loop is the difficulty of picking out the actual loop exit
location(s). Allowing name-binding expressions would fix this in some
simple cases, but not in the general (and more problematic) case of multiple
loop exits far from the loop start.
3. On the other hand, adding name-binding expressions practically invites
obfuscation, to which python is fairly resistant.
Thus what is really needed (IMNSHO) is an extension of the while loop syntax
which brings loop exits up to the top indentation level. For example:
while 1:
line = readline()
and while line:
# use line
and while not someotherreasontostopprocessing:
# do some more processing
instead of:
while 1:
line = readline()
if not line: break
# use line
if someotherreasontostopprocessing: break
# do some more processing
Guido van Rossum
> while 1:
> line = readline()
> and while line:
> # use line
> and while not someotherreasontostopprocessing:
> # do some more processing
I like it! I'll keep this in mind for Python 2.0. It's not as
powerful as break (which can be nested inside several other if
statements) but that's its strength...
Evan Simpson
the Python 'and while' syntax" to my resume <wink>.
Guido van Rossum wrote in message
<1999010420...@eric.cnri.reston.va.us>...
Robin Becker
Rossum <gu...@CNRI.Reston.VA.US> writes
>Evan Simpson write:
>
>> while 1:
>> line = readline()
>> and while line:
>> # use line
>> and while not someotherreasontostopprocessing:
>> # do some more processing
>
>powerful as break (which can be nested inside several other if
>statements) but that's its strength...
>
block? I've almost got used to this now and then you say you want to
start busting it. Puzzledly yrs
--
Robin Becker
Tim Peters
> Hmm. I once propsed a syntax for assignment in expressions, but
> have since changed my mind.
Told ya so <wink>.
> I'll tell you why.
>
> 1. There is exactly one place where this sort of notation would be
> useful: the condition expression of a while loop. In every other
> case, performing the name binding first as a separate statement
> imposes no real penalty.
Note the other one that's often brought up in the same breath:
m = re.search('a', line)
if m:
print "it's an a"
else:
m = re.search('b', line)
if m:
print "it's a b"
else:
m = re.search('c', line)
if m:
print "it's a c"
else:
# etc
For all the ways to worm around that, none is close to the flat
if/elif/elif/... assignment expressions would allow. There's plenty of that
going on in Python's implementation, too <0.7 wink>.
> ...
> Thus what is really needed (IMNSHO) is an extension of the while
> loop syntax which brings loop exits up to the top indentation level.
> For example:
>
> while 1:
> line = readline()
> and while line:
> # use line
> and while not someotherreasontostopprocessing:
> # do some more processing
Yes, that's a nice spelling! Stop people from whining about endlessly
nested if/else too, and I vote you can take the rest of the year off
<smile>.
now-about-that-"while-1"-...-ly y'rs - tim
Stefan Franke
1. It provides no easy idiom for a "repeat ... until p" loop, so you
have to write either
while 1:
[...]
if p: exit # as usual
or
while 1:
[...]
and while not p: pass # not an improvement
2. I think an additional structured exit construct should also be
usable in for-loops (one could argue about it's necessity in finite
loops).
Christian Tismer
>
> Evan Simpson write:
>
> > while 1:
> > line = readline()
> > and while line:
> > # use line
> > and while not someotherreasontostopprocessing:
> > # do some more processing
>
> powerful as break (which can be nested inside several other if
> statements) but that's its strength...
This is a real invention. I'm happy that it might make it
into P2000. It reduces lots of indentation and gives
more readability.
Now, since while also has an else part, this single else
would be executed if no break is issued, and one of
the partial whiles failed.
The analogy for if:
if initialcondition:
constraint = compute_othercondition()
and if constraint in allowed_cases:
do_more()
even_more = decide_more()
and if evenmore:
do_the_thing()
else:
bail_out_with_cleanup()
In standard Python, this construct would look
much more complicated:
bailout = 1
if initialcondition:
constraint = compute_othercondition()
if constraint in allowed_cases:
do_more()
even_more = decide_more()
if evenmore:
do_the_thing()
bailout = 0
elif bailout:
bail_out_with_cleanup()
I believe, "and if" leads to code which is easier to maintain,
also since new tests can be injected without having to
change indentation.
happy new year - chris
--
Christian Tismer :^) <mailto:tis...@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgp.ai.mit.edu/
we're tired of banana software - shipped green, ripens at home
Guido van Rossum
> >> while 1:
> >> line = readline()
> >> and while line:
> >> # use line
> >> and while not someotherreasontostopprocessing:
> >> # do some more processing
Robin Becker writes:
> but doesn't it break the fundamental lexical look of the statement
> block? I've almost got used to this now and then you say you want to
> start busting it. Puzzledly yrs
To be honest, I have no idea what you mean by the "fundamental lexical
look of the statement block". The proposed syntax is similar to
if <test>:
<stmts>
elif <test>:
<stmts>
else:
<stmts>
or, if you like, to
try:
<stmts>
except <expr>:
<stmts>
Evan Simpson
>Note the other one that's often brought up in the same breath:
[marching if-else snippped]
>For all the ways to worm around that, none is close to the flat
>if/elif/elif/... assignment expressions would allow. There's plenty of
that
>going on in Python's implementation, too <0.7 wink>.
[snippage]
>Yes, that's a nice spelling! Stop people from whining about endlessly
>nested if/else too, and I vote you can take the rest of the year off
><smile>.
Chris Tismer did it for me. Do I get credit for inspiring him?
m = re.search('a', line)
if m:
print "it's an a"
else:
m = re.search('b', line)
and if m:
print "it's a b"
else:
m = re.search('c', line)
and if m:
print "it's a c"
else:
# etc
Not as pretty as inline name-binding, but as in the "while" case, it solves
an entirely different problem which the other solution doesn't touch
(endlessly nested ifs).
For anyone who finds the semantics of the above obscure, it simply adds two
effects to an if-block. First, any if/elif/else suite can be followed by an
"and if" suite, which executes if the preceding suite completes, and the
conditional evaluates true. If the conditional evaluates false, execution
skips to the next "elif" or "else". The second effect is a corollary of the
first; We can now have multiple "else" suites in an if-block if all but the
last are followed by "and if"s. I leave the parsing of that as an exercise
for Guido <wink>.
>now-about-that-"while-1"-...-ly y'rs - tim
How about an empty "while:", or a simple compile-time optimization of
descriptive constant constructs like:
while "we have lines to process":
Ooh, ooh, while I'm in a syntactic frenzy, consider this spelling for
indexed for-loops:
for x[i] in exes:
# i is the for-loop counter
for [a, b, c][i] in lists:
# not ambiguous, but a little weird-looking.
for a, b, c[i] in tuples:
# should this be legal, or should parens be required? I would say the
latter.
Evan
Magnus L. Hetland
>
> For anyone who finds the semantics of the above obscure, it simply adds two
> effects to an if-block. First, any if/elif/else suite can be followed by an
> "and if" suite, which executes if the preceding suite completes, and the
> conditional evaluates true. If the conditional evaluates false, execution
> skips to the next "elif" or "else". The second effect is a corollary of the
> first; We can now have multiple "else" suites in an if-block if all but the
> last are followed by "and if"s. I leave the parsing of that as an exercise
> for Guido <wink>.
So -- to put it simply, the "and"-part replaces an indent, so that the
rest is on the same level? That's what it means, isn't it? (I realize
that that's not what it means in the while-loop, since it needs to
break out of the loop as well...)
Sounds nice... Makes me wonder why we don't write "else if". Maybe
it should be "andif" or "anif"? <wink>
> Ooh, ooh, while I'm in a syntactic frenzy, consider this spelling for
> indexed for-loops:
>
> for x[i] in exes:
> # i is the for-loop counter
Cool... Except that it conflicts with current syntax. All I have to do
is put "x=[0]; i=0" before this statement, and it would work -- which
would perhaps make this sort of thing a bit ambigous...? (I think
"indexing" is clearer, but...)
Magnus L. Hetland
> The problem with
>
> line = fp.readline()
> while line:
> ...
> line = fp.readline()
>
> is if you have to do other things before you assign to line (you'll then
> need to keep your code in sync). Which leads to the ugly while 1
> idiom....
What do you mean? (I'm sorry if I'm slow here...)
while 1:
line = fp.readline()
if not line: break
processing()
is (AFAICS) completely equivalent to:
line = fp.readline()
while line:
processing()
line = fp.readline()
where processing() can be almost anything...
Is there a difference that I'm missing here somewhere? And, of course;
if you want to escape in the middle of the loop, you'll have to use
break... (Although the "and while" syntax seems to solve a lot
there... :)
Anyway -- why isn't it possible to escape more than one loop? If it
were, several problems could be solved quite elegantly in coroutine
style... But of course, "while 1" would appear again... <shiver>. I
think a separate loop type with an optional label which was used for
this might be nice...
Returning to the partition problem:
[initialization...]
loop partition:
loop move_i:
i = i+1
if i == j: escape partition
if A[i] > v: escape move_i
loop move_j:
j = j-1
if j == i: escape partition
if A[j]<v: escape move_j
A[j] = v
Thus one could transfer control between the two loops until the main
loop was finished. (This is of course doable by using a function
instead of the partition loop, with a while 1 wrapper, and using
return instead of escape partition, but the last assignment would have
to be elsewhere, and one couldn't have more than 2 levels...)
>
> Using
>
> for line in fp.readlines():
> ...
>
> would work great, except it's quite a strain when the file length
> approches 1Gb (actually a long time before that, but you get my point...)
> It is also not general.
Right... (I guess it *would* be possible to make a lazy implementation
of readlines()... Well... fileinput is probably.py the thing to use.)
Evan Simpson
>So -- to put it simply, the "and"-part replaces an indent, so that the
>rest is on the same level? That's what it means, isn't it? (I realize
>that that's not what it means in the while-loop, since it needs to
>break out of the loop as well...)
Well, yes. Too clear and straightforward, for my tastes, though <wink>.
>Sounds nice... Makes me wonder why we don't write "else if". Maybe
>it should be "andif" or "anif"? <wink>
I wouldn't mind "else if" as a synonym for "elif", but "anif" is evil!
[Insufficiently well thought-out for-index proposal snipped]
>Cool... Except that it conflicts with current syntax. All I have to do
>is put "x=[0]; i=0" before this statement, and it would work -- which
>would perhaps make this sort of thing a bit ambigous...? (I think
>"indexing" is clearer, but...)
D'oh! Teaches me not to suggest a spelling without trying it out first.
Mmmm... indexing
Evan
Bjorn Pettersen
"Magnus L. Hetland" wrote:
>
> Bjorn Pettersen <bj...@roguewave.com> writes:
>
> > The problem with
> >
> > line = fp.readline()
> > while line:
> > ...
> > line = fp.readline()
> >
> > is if you have to do other things before you assign to line (you'll then
> > need to keep your code in sync). Which leads to the ugly while 1
> > idiom....
>
> What do you mean? (I'm sorry if I'm slow here...)
Assuming you need to compute some lengthy expression, you would have to
replicate it:
x = f(a) + g(b) / h(c)
while x:
process(x)
x = f(a) + g(b) / h(c)
If you suddenly realize it should have been g(a) instead, you need to
change your code in two places -- if you forget, your code is out of
sync (very frequent source of bugs).
I don't mind the "and while" proposal except for the "while 1" and "and
while" part <wink>. My suggested spelling would be (hopefully
semantically clearer):
do:
line = fp.readline()
while line:
process(line)
else:
cleanup()
It still doesn't solve Tim's match-object problem, but my parsing rarely
uses the re module so I'll let Tim fight for this one <.3 wink>
-- bjorn
Magnus L. Hetland
> Magnus L. Hetland wrote in message ...
>
> >Sounds nice... Makes me wonder why we don't write "else if". Maybe
> >it should be "andif" or "anif"? <wink>
>
> I wouldn't mind "else if" as a synonym for "elif", but "anif" is
> evil!
Any others agree? Guido -- can we *please* have "else if"? "elif" only
reminds me of "fi" and "esac" and the like... (and "anif", for that
matter ;)
>
> D'oh! Teaches me not to suggest a spelling without trying it out first.
>
> Mmmm... indexing
What about a builting function "indexed"? (OK -- this might not be new
stuff...)
def indexed(list):
return map(None,list,range(len(list)))
for el,i in indexed(list):
...
> Evan
Michael P. Reilly
: [Regarding]
And, more relevantly, to
while <test>:
<stmts>
else:
<stmts>
Magnus L. Hetland
>
> And, more relevantly, to
> while <test>:
> <stmts>
> else:
> <stmts>
>
<stupid question>
What does the "else" part here do that wouldn't work without it?
while <test>:
<stmts>
<stmts>
Where's the difference? (I guess I should consult the language
reference, but...)
</stupid question>
Michael Vezie
while assign(line, foo.readline()):
print line
The assign() function would take two arguments. It would assign the
second to the first, and return the second (just like = does in C).
It could also be used in lambda expressions (where the lack of
assignment can be really frustrating). Granted, there scoping
becomes an issue, so maybe something like 'gassign', which assumes
global scoping could be used.
Just my two cents worth.
Michael
Paul Prescod
>
> Not as pretty as inline name-binding, but as in the "while" case, it solves
> an entirely different problem which the other solution doesn't touch
> (endlessly nested ifs).
You've made the nesting itself redundant, but the logic seems just as
complex. Reducing the complexity of the syntax doesn't really help.
> How about an empty "while:",
Perhaps spelled "do:"
> or a simple compile-time optimization of
> descriptive constant constructs like:
>
> while "we have lines to process":
People will think that Python acts on English prose! Depending on their
experience with COBOL they may think that is a Bad Thing.
> Ooh, ooh, while I'm in a syntactic frenzy, consider this spelling for
> indexed for-loops:
>
> for x[i] in exes:
> # i is the for-loop counter
I'm not clear on the value of "x". Shouldn't this be:
for exes[i] in exes:
...
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco
"In spite of everything I still believe that people are basically
good at heart." - Anne Frank
Michael P. Reilly
: "Michael P. Reilly" <arc...@shore.net> writes:
:>
:> And, more relevantly, to
:> while <test>:
:> <stmts>
:> else:
:> <stmts>
:>
: What does the "else" part here do that wouldn't work without it?
: while <test>:
: <stmts>
: <stmts>
: Where's the difference? (I guess I should consult the language
: reference, but...)
Examples speak louder (and more clearly) than [my] explainations. :)
def index(self, item):
"""(Re)impliment the index method for UserList in Python."""
i = 0
while i < len(array):
if array[i] == item:
break
else:
# this section is only executed if the break is never executed
raise IndexError, item
return i
If there is no break inside the while loop at all, then yes, it would
work just as if there is no "else:" clause.
For statements works the same way:
def is_sorted(list_of_numbers):
last = None
for item in list_of_numbers:
if last >= item:
break
last = item
else:
return 1 # in order
return 0 # out of order
The only problem with this is the starting value: I'm assuming cmp(None, x)
for all x except None; although I cannot find this explicitly in the
language reference.
Evan Simpson
>You've made the nesting itself redundant, but the logic seems just as
>complex. Reducing the complexity of the syntax doesn't really help.
My hope is that this notation would make the "tail nesting" logic a bit more
explicit and prevent marching indents. Obviously the logic is just as
complex since it hasn't changed at all :-)
>> How about an empty "while:",
>
>Perhaps spelled "do:"
Well, if we're going to talk new keywords, my vote would go to "loop" or
"repeat". I'd be perfectly pleased to find Python 2.0 allowing me to write:
repeat "outer":
# stuff
repeat while test1:
# more stuff
if test2:
break "outer"
while test3:
# yet more stuff
until test4:: # double colon is synonym for "pass" body.
>> for x[i] in exes:
>> # i is the for-loop counter
>
>I'm not clear on the value of "x". Shouldn't this be:
>
>for exes[i] in exes:
The intent was that this would work the same as "for x in exes:" combined
with "for i in range(len(exes))". Unfortunately it turns out to be utterly
broken as a potential spelling.
Mmmm... new keywords
Evan Simpson
Michael P. Reilly
: Anyway -- why isn't it possible to escape more than one loop? If it
: were, several problems could be solved quite elegantly in coroutine
: style... But of course, "while 1" would appear again... <shiver>. I
: think a separate loop type with an optional label which was used for
: this might be nice...
: Returning to the partition problem:
: [initialization...]
: loop partition:
: loop move_i:
: i = i+1
: if i == j: escape partition
: if A[i] > v: escape move_i
: loop move_j:
: j = j-1
: if j == i: escape partition
: if A[j]<v: escape move_j
: A[j] = v
: Thus one could transfer control between the two loops until the main
: loop was finished. (This is of course doable by using a function
: instead of the partition loop, with a while 1 wrapper, and using
: return instead of escape partition, but the last assignment would have
: to be elsewhere, and one couldn't have more than 2 levels...)
Agh!! Labels and gotos (disguised as "escape") again?!?
Computer scientists have already proven that even break and continue
are never need in an algorithm. We don't need to go into the Perl hole
by adding labels, do we? Obfuscated C programmers rarely even used
goto and labels (way back when I was paying attention to that contest ;).
What is wrong with:
i_stop = j_stop = 0
while i != j and not i_stop and not j_stop:
while i < j and not i_stop:
i = i + 1
if A[i] > v: i_stop = 1
while j > i and not j_stop:
j = j - 1
if A[j] < v: j_stop = 1
A[j] = v
The label-escape methods are the same order of complexity. And if you needed
to, you could more easily do (though it doesn't look as nice):
try:
while 1:
try:
while 1:
i = i + 1
if i == j:
raise IndexError, 'outside loop'
if A[i] > v:
raise IndexError, 'inside loop'
except IndexError, value:
if value == 'outside loop': raise IndexError
try:
while 1:
j = j - 1
if i == j:
raise IndexError, 'outside loop'
if A[j] < v:
raise IndexError, 'inside loop'
except ValueError:
if value == 'outside loop': raise IndexError
except IndexError: pass
A[j] = v
Both are decent implimentations of your loop-escape construct.
What need is there of adding labels? If anything, I would rather see
something more akin to Bourne shells "break" command where you put the
level to break (not that I'm asking for that :).
-Arcege
Guido van Rossum
interacts with a following else. ('and while' is still okay).
Re: 'else if' vs 'elif' ... Maybe for another language.
Christian Tismer
...
[Tim]
> >Yes, that's a nice spelling! Stop people from whining about endlessly
> >nested if/else too, and I vote you can take the rest of the year off
> ><smile>.
>
> Chris Tismer did it for me. Do I get credit for inspiring him?
Yes, you got 1024 bits for free. (Used shifted ones, of course :)
> m = re.search('a', line)
> if m:
> print "it's an a"
> else:
> m = re.search('b', line)
> and if m:
> print "it's a b"
> else:
> m = re.search('c', line)
> and if m:
> print "it's a c"
> else:
> # etc
>
No, I don't believe that this the right thing.
If at all, there should be only one else which
means "if that all fails".
if test:
side_effects()
and if test:
side_effects()
else
something_else()
ciao - chris
Evan Simpson
<36927D82...@appliedbiometrics.com>...
>Evan Simpson wrote:
>> Chris Tismer did it for me. Do I get credit for inspiring him?
>
>Yes, you got 1024 bits for free. (Used shifted ones, of course :)
idea, tho.
>No, I don't believe that this the right thing.
>If at all, there should be only one else which
>means "if that all fails".
I thought you might mean that, but I wanted to be able to tackle Tim's
example. Without a way to spell "else" for each "and if", you can't do the
kind of alternation it needs. I wanted to be able to flatten:
if a:
#1
else:
#2
if b:
#3
else:
#5
if c: #etc
but with only one catchall else, an "and if" clause could only flatten:
if a:
#1
if b:
#2
if c: #etc
This is all moot, of course, since Guido's shot it down, along with it's
lil' buddy "else if" <sniff> due to potential confusion.
Mmmm... shifted bits
Evan Simpson
Greg Gritton
You answered your own question here.
The top version of the code looks the nicest, and is by
far the easiest to understand.
Although I find Python cleaner than Perl in almost every
way, one of the things I like about perl is the labeled loops.
Greg Gritton
Robin Becker
<arc...@shore.net> writes
> while <test>:
> <stmts>
> else:
> <stmts>
>
--
Robin Becker
Tim Peters
> [more looping about]
> ...
> It still doesn't solve Tim's match-object problem, but my parsing rarely
> uses the re module so I'll let Tim fight for this one <.3 wink>
The "infinitely nested re matching problem" is a specific instance of the
"infinitely nested function with a special return-value problem".
Curiously, they're problems I don't seem to have! It's a meta-problem for
me: I get tired of trotting out the workarounds every month, and wince all
the while because the straightforward "if x:=f()/elif x:=f()/..." approach
the complainer suggests at the start is a heck of a lot clearer than the
alternatives (at least in simple cases) anyway. I'm generally no fan of
implicit side-effects, but these are explicit, and already widely available
in major languages ranging from Icon to Perl, not to mention minor ones like
Java and C <wink>.
fortran-is-the-measure-of-all-things-ly y'rs - tim
Tim Peters
> Yes, that's [and while xxx:] a nice spelling! Stop people from whining
> about endlessly nested if/else too, and I vote you can take the rest of
> the year off <smile>.
[Evan "The Purportedly Young" Simpson]
> Chris Tismer did it for me. Do I get credit for inspiring him?
>
> m = re.search('a', line)
> if m:
> print "it's an a"
> else:
> m = re.search('b', line)
> and if m:
> print "it's a b"
> else:
> m = re.search('c', line)
> and if m:
> print "it's a c"
> else:
> # etc
Yes, you got full credit for inspiring him -- but lost it twice over for
repeating that mess.
next-time-quit-while-you're-ahead<wink>-ly y'rs - tim
Russell Nelson
> Evan Simpson write:
>
> > while 1:
> > line = readline()
> > and while line:
> > # use line
> > and while not someotherreasontostopprocessing:
> > # do some more processing
>
> I like it! I'll keep this in mind for Python 2.0. It's not as
> powerful as break (which can be nested inside several other if
> statements) but that's its strength...
How about a language feature stolen from HP's old SPL II (System
Programming Language II, not to be confused with plain old SPL) for
the HP 3000?
repeat
line = readline()
while line:
# use line
until someothertest
Parts of this can be left out:
repeat
line = readline()
until someothertest
or
while line:
# use line
--
-russ nelson <rn-...@crynwr.com> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Christian Tismer
>
> "Michael P. Reilly" <arc...@shore.net> writes:
>
> >
> > And, more relevantly, to
> > while <test>:
> > <stmts>
> > else:
> > <stmts>
> >
>
> What does the "else" part here do that wouldn't work without it?
>
> while <test>:
> <stmts>
>
> <stmts>
>
> Where's the difference? (I guess I should consult the language
> reference, but...)
<stupid kind="answer">
Now, the else doesn't do anything different but this:
If the loop breaks by break, it is not executed.
This is similar to for:
for thing in list:
do_something
if somecondition: break
else:
do this if we didn't break.
<mode advocacy="pro">
for elem in list: suite
else: suite
So else what? It implies an intent to find something
in the list which meets some condition, and we break with
it. The else handles the case that we didn't find any.
while condition: suite
else: suite
Again it implies hat we want to break at some item,
and else handles the "not found" case.
if condition: suite
else: suite
This now looks like a shortcut of
while condition: suite_which_breaks
else: suite
</mode>
<mode purist="on">
The else part of for and while is seldom used.
Its logic is not so very obvious. It appears to
me as an early attempt to bring some orthogonalism
into the language. Today, Guido's priorities
look different, and I don't believe that these else's
would make it into the language today.
</mode>
</stupid><!-- hard to switch this off for me :-->
cetero-censeo-global-esse-delendam - ly y'rs - chris
Gordon McMillan
[lots of stuff]
> The else part of for and while is seldom used.
> Its logic is not so very obvious. It appears to
> me as an early attempt to bring some orthogonalism
> into the language. Today, Guido's priorities
> look different, and I don't believe that these else's
> would make it into the language today.
>
> </mode>
> </stupid><!-- hard to switch this off for me :-->
I use the for / else construction frequently. It saves a 'found'
variable, and the attendant danger of making silly errors. I love it.
I've never used while / else.
while 1: <suite>
else: <suite2>
is, of course, useless.
If I'm doing
while <test> : <suite>
instead of "for", it's because <suite> is influencing <test> in more
complex ways than a simple increment, and there's probably no "break"
in there at all.
Since I've finally broken down and contributed to this thread, let me
say that I find the current constructs very clear and more than
adequately powerful. Most of the alternatives seem less than clear.
I am somewhat intrigued by the straightforward assingment in
conditional ( favoring " := " ). Despite the USDA warnings, I use
this in C / C++ all the time, where I find that the errors avoided by
"only typing it once" outweigh the errors encountered by "typing it
wrong".
addicted-to-living-on-the-edge-<snort>-ly y'rs
- Gordon
Magnus L. Hetland
> I think the 'and if' proposal is too confusing, because of the way it
> interacts with a following else. ('and while' is still okay).
>
> Re: 'else if' vs 'elif' ... Maybe for another language.
Well -- I think most other languages are covered already in this
respect <wink>
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
--
Magnus L. Hetland
[..]
> Well, if we're going to talk new keywords, my vote would go to "loop" or
> "repeat". I'd be perfectly pleased to find Python 2.0 allowing me to write:
>
> repeat "outer":
loop "outer" or loop outer would indicate naming a loop. repeat
"outer" seems like repeating a string... :)
> # stuff
> repeat while test1:
Why not just while test1?
> # more stuff
> if test2:
> break "outer"
I like this too...
> while test3:
> # yet more stuff
> until test4:: # double colon is synonym for "pass" body.
What does this mean?
[...]
> The intent was that this would work the same as "for x in exes:" combined
> with "for i in range(len(exes))". Unfortunately it turns out to be utterly
> broken as a potential spelling.
My idea of indexed(list) is retracted in favour of list.indexed().
Thus:
for x,i in list.indexed():
print "Element %s is %s" % (i,x)
>
> Mmmm... new keywords
> Evan Simpson
--
Magnus L. Hetland
> Guido van Rossum <gu...@CNRI.Reston.VA.US> writes:
>
[...]
>
> How about a language feature stolen from HP's old SPL II (System
> Programming Language II, not to be confused with plain old SPL) for
> the HP 3000?
>
> repeat
> line = readline()
> while line:
> # use line
> until someothertest
Meaning? I generally like to be able to paraphrase these things in
natural language -- it seems a bit difficult here... The repeat and
while is at the same level, right? Does the while-part simply work
like an if-statement? Or can it end the repeat loop?
Anyway -- perhaps a more pythonesque spelling (without a block-ending
statement) would be something like:
until someothertest:
line = readline()
while line:
# use line
Hm. I guess this might be even more confusing (and at least
syntactically ambigous).
Magnus L. Hetland
> "Magnus L. Hetland" wrote:
[...]
> x = f(a) + g(b) / h(c)
> while x:
> process(x)
> x = f(a) + g(b) / h(c)
>
I see. I agree with you too. This duplication of code *is* a symptom
of lacking control structures. However -- you can quite easily solve
the problem by encapsulating it (though there is of course, still
duplication... Sigh.)
f = lambda: f(a) + g(b) / h(c)
x = f()
while x:
process(x)
x = f()
(OK -- so it's not pretty...)
> I don't mind the "and while" proposal except for the "while 1" and "and
> while" part <wink>. My suggested spelling would be (hopefully
> semantically clearer):
>
> do:
> line = fp.readline()
> while line:
> process(line)
> else:
> cleanup()
What about several "and while" parts? And the "while line" could be
confused with a normal while loop... (And to me, "do" does not suggest
looping...)
What about:
repeat:
line = fp.readline()
and while line:
result = process(line)
and while result:
print "We got another result:", result
else:
cleanup()
I guess the only thing here is "while 1" == "repeat"
Christian Tismer
>
> Christian Tismer, pretending to be in "stupid" <HA!> mode, writes:
> [lots of stuff]
I can do even worse :o)
> I use the for / else construction frequently. It saves a 'found'
> variable, and the attendant danger of making silly errors. I love it.
>
> I've never used while / else.
I agree. With for it makes sense.
...
> I am somewhat intrigued by the straightforward assingment in
> conditional ( favoring " := " ). Despite the USDA warnings, I use
> this in C / C++ all the time, where I find that the errors avoided by
> "only typing it once" outweigh the errors encountered by "typing it
> wrong".
Do you want a really ugly, really stupid proposal?
Here it is, you will wonder:
# simple while
line = f.readline()
while line:
do_stuff()
line = f.readline()
# sugared while:
while line:=f.readline()
do_stuff()
I'm sure it is very hard to do this wrong.
But I'm much more sure that it is hard to get
this through as a proposal, so I retract it
in advance.
don't-hurt-me-I'm-a-simple-stupid -ly y'rs chrisdom
sk...@calendar.com
> m = re.search('a', line)
> if m:
> print "it's an a"
> else:
> m = re.search('b', line)
> and if m:
> print "it's a b"
> else:
> m = re.search('c', line)
> and if m:
> print "it's a c"
> else:
> # etc
Other than saving a couple redundant tests, how is the above different (or
more readable) than
m = re.search('a', line)
if m:
print "it's an a"
else:
m = re.search('b', line)
if m:
print "it's a b"
else:
m = re.search('c', line)
if m:
print "it's a c"
else:
# etc
?
--
Skip Montanaro
Mojam: http://www.mojam.com/
Musi-Cal: http://concerts.calendar.com/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Magnus L. Hetland
> Magnus L. Hetland <m...@idt.ntnu.no> wrote:
> [readline loop section snipped]
>
[...]
>
> Agh!! Labels and gotos (disguised as "escape") again?!?
Come on... Every control structure is a disguised "goto". It's just a
matter of selecting the ones that give you enough expressive power, so
you don't have to resort to contrived solutions like boolean status
variables and the like.
>
> Computer scientists have already proven that even break and continue
> are never need in an algorithm.
Certainly. And neither is "for" or "else", for instance. So what?
> We don't need to go into the Perl hole
> by adding labels, do we?
Agreed. We won't go into any Perl hole by adding labels. There is no
correlation :)
> Obfuscated C programmers rarely even used
> goto and labels (way back when I was paying attention to that contest ;).
What does that have to do with anything? Do you mean it's too
obfuscated for them? I doubt that...
>
> What is wrong with:
> i_stop = j_stop = 0
> while i != j and not i_stop and not j_stop:
> while i < j and not i_stop:
> i = i + 1
> if A[i] > v: i_stop = 1
> while j > i and not j_stop:
> j = j - 1
> if A[j] < v: j_stop = 1
> A[j] = v
Nothing really... I just wanted to demonstrate the control structure
handling the problem directly. In your case, you have to resort to
(the usual) boolean variables. Are they really any better, do you
think? The result is the same, at the cost of some extra clutter.
>
> The label-escape methods are the same order of complexity. And if you needed
> to, you could more easily do
More easily? Well -- as long as the stuff isn't implemented, sure -- but...
[horrible example snipped]
>
> What need is there of adding labels? If anything, I would rather see
> something more akin to Bourne shells "break" command where you put the
> level to break (not that I'm asking for that :).
Why not just have gotos with line numbers? ;)
Magnus L. Hetland
> Another thought. What about an assign function, as in:
>
> while assign(line, foo.readline()):
> print line
I think this is prettier than line := foo.readline... (I don't really
like having two assignment operators...)
The problem is the non-standard parameter-modification thing... I
It can be implemented already, if you use a single-element-list or
something for line:
def assign(list, value):
list[0] = value
return value
line = [0]
while assign(line, foo.readline()):
print line[0]
Is there a good way to solve this? Mabye
while line assigned fp.readline():
print line
This would make some meaning semantically too... "While the variable
line, assigned fp.readline(), has a value, do the following:"
It probably makes more sence than the ordinary assignment operator...
("While line is assigned to fp.readline (meaning that it also has a
value) do the following...")
> It could also be used in lambda expressions (where the lack of
> assignment can be really frustrating).
I guess the the assigned thing can be used there too. "a assigned b"
is an expression meaning "the value of a after it has been given the
value of b" with the side effect of actually giving a the value of b.
Michael McLay
> Since I've finally broken down and contributed to this thread, let me
> say that I find the current constructs very clear and more than
> adequately powerful. Most of the alternatives seem less than clear.
Creeping featurism Batman, has the Python community gone bonkers!!!
This thread seems to have lost sight of the KISS philosophy of
Python. We don't NEED ten different ways to do the same thing.
Having only one way to implement a loop, even if it sometime
requires a few additional lines of code, results in everyone writing
code that is similar in style.
Adding a feature increases the time required to master the language
and it tends to make it harder to read code written by others. Also,
coding styles will increase geometrically with the number of
features. Not being able to quickly decipher code written by others
will decrease productivity. This loss could easily wipe out any gains
of programming efficiency that might be made by adding YARF (Yet
Another Redundant Feature).
Ok, some of the suggestions have been very interesting, but I thought
someone should chime in with the "don't fix it cause it ain't boken"
point of view. It's comforting to know that our benevolent dictator
has minimalist tastes.
Andrew M. Kuchling
>The else part of for and while is seldom used.
>Its logic is not so very obvious. It appears to
>me as an early attempt to bring some orthogonalism
>into the language. Today, Guido's priorities
It's also possible that they're not commonly used because
other languages don't have them; if your thinking has been molded by
other languages, they don't leap to mind when writing code.
Personally, I always have a faintly surprised feeling every time
for/else and while/else are brought up; "oh yeah, Python has those,
doesn't it?". Sometimes I wonder whether there are many places where
for/else and while/else would have made things clearer, if every line
of my code was examined carefully. On the other hand, maybe they
*are* not very useful. Beats me...
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
Real-world problems are often "high-dimensional", that is, are described by
large numbers of dependent variables. Algorithms must be specifically designed
to function well in such high-dimensional spaces.
-- David Rogers, "Weather Prediction Using a Genetic Memory"
Magnus L. Hetland
> Gordon McMillan wrote:
[...]
>
> # sugared while:
>
> while line:=f.readline()
> do_stuff()
>
This has been proposed several times before, no? (Except with a colon
after the while-line... ;)
> I'm sure it is very hard to do this wrong.
> But I'm much more sure that it is hard to get
> this through as a proposal, so I retract it
> in advance.
Well -- what about my keyword meaning essentially the same,
"assigned"?
while line assigned f.readline():
do_stuff()
Declarative reading of an assignment, with the side-effect that the
assignment is actually carried out...
I kinda like it myself... (It's like "while line (assigned something)
has a value...")
I guess it still sneaks assignments into expressions, but at least
with a quite understandable syntax IMNSHO.
If on wants it even clearer (that is, if one is compulsive) one might
even write something like:
while line assigned f.readline() is not None:
do_stuff()
It's verbose, but meaningful -- intuitively more so than using := IMO
> don't-hurt-me-I'm-a-simple-stupid -ly y'rs chrisdom
probably-so-stupid-I-don't-even-know-it'ly y'rs --M
Magnus L. Hetland
> Gordon McMillan writes:
>
> > Since I've finally broken down and contributed to this thread, let me
> > say that I find the current constructs very clear and more than
> > adequately powerful. Most of the alternatives seem less than clear.
>
> Creeping featurism Batman, has the Python community gone bonkers!!!
>
> This thread seems to have lost sight of the KISS philosophy of
> Python. We don't NEED ten different ways to do the same thing.
> Having only one way to implement a loop, even if it sometime
> requires a few additional lines of code, results in everyone writing
> code that is similar in style.
Well spoken :)
Maybe we should use some more general control structure, and eradicate
the simple while loop...
gone-quite-bonkers-from-creeping-featurism'ly y'rs --M
Lloyd Zusman
> Michael McLay <mc...@nist.gov> writes:
> >
> > [ ... ]
> >
> > This thread seems to have lost sight of the KISS philosophy of
> > Python. We don't NEED ten different ways to do the same thing.
> > Having only one way to implement a loop, even if it sometime
> > requires a few additional lines of code, results in everyone writing
> > code that is similar in style.
>
> Well spoken :)
>
> Maybe we should use some more general control structure, and eradicate
> the simple while loop...
Yes ... how about replacing the simple while loop with the "goto"
control structure.
<ducking>
--
Lloyd Zusman
l...@asfast.com
Michael T. Richter
<13971.30657....@amarok.cnri.reston.va.us>...
>>The else part of for and while is seldom used.
>>Its logic is not so very obvious. It appears to
>>me as an early attempt to bring some orthogonalism
>>into the language. Today, Guido's priorities
> It's also possible that they're not commonly used because
>other languages don't have them; if your thinking has been molded by
>other languages, they don't leap to mind when writing code.
>Personally, I always have a faintly surprised feeling every time
>for/else and while/else are brought up; "oh yeah, Python has those,
>doesn't it?". Sometimes I wonder whether there are many places where
>for/else and while/else would have made things clearer, if every line
>of my code was examined carefully. On the other hand, maybe they
>*are* not very useful. Beats me...
While and for have else clauses? [does rapid check] Hey, cool!
--
Michael T. Richter <m...@ottawa.com> http://www.igs.net/~mtr/
PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
Michael T. Richter
> Maybe we should use some more general control structure, and eradicate
> the simple while loop...
Doesn't Eiffel do precisely this? It's been a while since I've looked at
Eiffel (because the available implementations sucked), but I seem to
remember it having precisely one looping construct which could be used to
emulate for/while/do loops of other languages without a whole lot of (albeit
some) extra typing.
Gordon McMillan
> Gordon McMillan writes:
>
> > Since I've finally broken down and contributed to this thread,
> let me > say that I find the current constructs very clear and more
> than > adequately powerful. Most of the alternatives seem less than
> clear.
>
> Creeping featurism Batman, has the Python community gone bonkers!!!
It's a semi-annual event. The Usenet equivalent of the Ladies
Auxiliary's Reenactment of Pearl Harbor.
- Gordon
Michael Scharf
> It's also possible that they're not commonly used because
> other languages don't have them; if your thinking has been molded by
> other languages, they don't leap to mind when writing code.
> Personally, I always have a faintly surprised feeling every time
> for/else and while/else are brought up; "oh yeah, Python has those,
> doesn't it?". Sometimes I wonder whether there are many places where
> for/else and while/else would have made things clearer, if every line
> of my code was examined carefully. On the other hand, maybe they
> *are* not very useful. Beats me...
I have the same feeling. This strange for/else and
while/else are interesting features but not very common in
other languages. I think the beauty of Python is that it
takes the nice and intuitive features of the "languages we
all know" and combines them to a beautiful picture. And
Python is like pseudo-code: if you know
C/Perl/Pascal/Java/... you can simply read most
examples. The while/else is something which is not like
pseudo-code, its strange and not very intuitive.
while condition:
do_something()
else:
do_something_else()
Intuitively, I would expect that the else clause is called
when the condition is false initially:
if condition:
while condition:
do_something()
else:
do_something_else()
but YMMV
Michael
--
''''\ Michael Scharf
` c-@@ TakeFive Software
` > http://www.TakeFive.com
\_ V mailto:Michael...@TakeFive.co.at
Christian Tismer
>
> Christian Tismer <tis...@appliedbiometrics.com> writes:
>
> > Gordon McMillan wrote:
> [...]
>
> >
> > # sugared while:
> >
> > while line:=f.readline()
> > do_stuff()
> >
>
> This has been proposed several times before, no? (Except with a colon
> after the while-line... ;)
Right, the fun in () was the only effect I was after.
Introducing ":=" by means of while: with an attached assignment.
Not serious enough to require an answer - chris
while oh:=()
forget_it()
Magnus L. Hetland
While we're talking about pseudocode and readability for others... One
thing that might not be easily readable for people who don't know
Python is the use of colon in slicing... Maybe an ellipse would be
easier? (At least I think so...)
for x in list[0..10]:
print x
(Isn't there an ellipse somewhere in some advanced slicing notation?
Where is that?)
Magnus L. Hetland
> m...@idt.ntnu.no (Magnus L. Hetland) writes:
>
[...]
> > Well spoken :)
> >
> > Maybe we should use some more general control structure, and eradicate
> > the simple while loop...
>
> Yes ... how about replacing the simple while loop with the "goto"
> control structure.
How about this:
We allow only the statements
- set_current
- clear_current
- right_if_zero
- left_if_zero
- right_if_one
- left_if_one
- goto <state>
and
- label <state>
where the movement (left/right) and the reading/writing refers to
memory-locations (or an imaginary paper-tape...) Absolutely no other
statements are allowed, and the <state> elements are only allowed to
be integers from 0 to 99. Of course the "tape" must be initialized,
and is done by writing the values like this:
0
1
0
0
0
1
1
0
1
... etc. before the program.
It's minimalistic, and it is Turing-complete. We don't need anything
more, do we? (Oh, wait -- perhaps there should be a "print" statement
or something...)
minimalistically y'rs --M
Gordon McMillan
Well Evan's a's aren't necessarily also b's and c's.
- Gordon
Michael T. Richter
> while condition:
> do_something()
> else:
> do_something_else()
My first reaction (a few hours ago) upon finding out that Python had
while/else and for/else was "cool!". Now I'm not so sure of that reaction.
Precisely what problem does while/else, for example, solve? The following
code snippet ...
a = 0;
while a < 10:
print a
a = a + 1
else:
print "Booger!"
... and the following code snippet ...
a = 0;
while a < 10:
print a
a = a + 1
print "Booger!"
... do exactly the same thing. What does the "else" clause add? (Similar
reservations exist in reference to for/else of course.) Can someone
enlighten me as to the benefits of this unusual structure?
Michael T. Richter
>My first reaction (a few hours ago) upon finding out that Python had
>while/else and for/else was "cool!". Now I'm not so sure of that reaction.
>Precisely what problem does while/else, for example, solve?
<snip>
>What does the "else" clause add? (Similar
>reservations exist in reference to for/else of course.) Can someone
>enlighten me as to the benefits of this unusual structure?
Never mind. I answered my own question with a bit more tinkering. For
those unenlightened souls (like I was about five minutes ago), the "else"
clause is executed iff there was no "break" in the while/for portion of the
loop.
I can see a use for this construct now that I've figured it out.
Michael Vezie
>> print line
>
>I think this is prettier than line := foo.readline... (I don't really
>like having two assignment operators...)
Yeah...
>Is there a good way to solve this? Mabye
>
>while line assigned fp.readline():
> print line
>
>This would make some meaning semantically too... "While the variable
>line, assigned fp.readline(), has a value, do the following:"
I'm not sure I like that as much; maybe it's my C background, but
I don't like operators that are words (still getting used to 'or'
instead of '||', etc).
>> It could also be used in lambda expressions (where the lack of
>> assignment can be really frustrating).
>
>I guess the the assigned thing can be used there too. "a assigned b"
>is an expression meaning "the value of a after it has been given the
>value of b" with the side effect of actually giving a the value of b.
I suppose any "assignment operator" method used will work in a lambda.
Here's a question for those more versed in the ways of Python; is it
possible to do an assignment now with various permutations of sys,
__locals__, and __setattr__, or something like that?
Michael
Michael Vezie
Michael T. Richter <m...@ottawa.com> wrote:
>Never mind. I answered my own question with a bit more tinkering. For
>those unenlightened souls (like I was about five minutes ago), the "else"
>clause is executed iff there was no "break" in the while/for portion of the
>loop.
The reson why I havn't used it is because, to me, it is counter-intuitive.
I think of "break" as an exception; a break from the normal flow of code.
The normal flow of a while is to go until until the condition is false.
The normal flow of a for is to go until the list is empty. And in the
case of if, the normal flow is when the condition is true. If you think
of if:
if <condition>:
code1
else:
code2
Then the else is called when the normal flow (code1) is not called.
So for me, in:
while <condition>:
code1
if <other condition>: break
else:
code2
I would expect code2 to be called when the normal flow does not happen
(ie, when you get a break). But it doesn't work that way. It's the
opposite.
Not that I'm proposing it be changed or anything...
Michael
Barry A. Warsaw
The notion of `and while' isn't bad but I'll propose using different
existing keywords: `continue if'. It reads better to me and combines
notions of both constructs it would be used in.
while 1:
line = fp.readline()
continue if line:
result = process(line)
continue if result:
print 'The result was:', result
This could be used in the cascading-re problem as well
mo = re.search('a', line)
if mo:
print 'found an a'
else:
mo = re.search('b', line)
continue if mo:
print 'found a b'
else:
mo = re.search('c', line)
continue if mo:
print 'found a c'
Better, but still not wonderful. Tim's right, if you just had return
value assignments in the test, a lot of things would be much clearer.
-Barry
Evan Simpson
all, there's nothing lacking in Python that a quick class or two won't fix,
eh Tim?
class Pita:
'''It's a little pocket for an object. What would you call it, smart
guy?'''
def __init__(self, v = None):
self._ = v
def __call__(self, *p):
if len(p)==1:
self._ = p[0]
return self._
# And now, that golden oldie, the match-problem! <Yaaah!>
m = Pita()
if m(re.search('a', line)):
print "it's an a"
elif m(re.search('b', line)):
print "it's a b"
elif m(re.search('c', line)):
print "it's a c"
m = m()
# And of the course, the ever-obsoleted-by-fileinput ...
line = Pita()
while line(f.readline()):
print line()
Mmmm... Classes.
Evan Simpson
Barry A. Warsaw
>>>>> "MLH" == Magnus L Hetland <m...@idt.ntnu.no> writes:
MLH> Well -- what about my keyword meaning essentially the same,
MLH> "assigned"?
| while line assigned f.readline():
| do_stuff()
Save the additional keyword and just use `is'
while line is f.readline():
do_stuff()
But I don't even mind := or even = if parens are required
while line := f.readline():
do_stuff()
while (line = f.readline()):
do_stuff()
GCC for example, will warn you if you tried to do the similar thing in
C and omitted the parens.
-Barry
Stewart Wilson
"Barry A. Warsaw" wrote:
>
> The notion of `and while' isn't bad but I'll propose using different
> existing keywords: `continue if'. It reads better to me and combines
> notions of both constructs it would be used in.
>
> while 1:
> line = fp.readline()
> continue if line:
> result = process(line)
> continue if result:
> print 'The result was:', result
I find the proposed 'continue if' counter-intuitive: 'continue' currently
directs the flow to the next iteration of the while loop, whereas 'continue if'
either allows the flow to fall to enclosed block, or it kicks the flow out of
the while loop entirely. I prefer the 'and while' notation.
--Stewart
These are personal opinions not those of Nortel Networks.
Paul Prescod
>
> Adding a feature increases the time required to master the language
> and it tends to make it harder to read code written by others.
I think that the goal here is actually to reduce the number of different
ways to write the same thing to one "most obvious" way and many "why would
you do that?" ways. Python has many precedents for this. Fans of truly
minimalist languages like Scheme claim not to need a standard object
system because it is so easy to build one yourself. Python says: "sure,
but a standard one will increase code readability."
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco
"You have the wrong number."
"Eh? Isn't that the Odeon?"
"No, this is the Great Theater of Life. Admission is free, but the
taxation is mortal. You come when you can, and leave when you must. The
show is continuous. Good-night." -- Robertson Davies, "The Cunning Man"
Stidolph, David
it's a a
it's a b
it's a c
m is set the first time and evaluates true for the other tests that
follow.
Better code would be
if re.search('a', line):
print "it's an a"
elif re.search('b', line):
print "it's a b"
elif re.search('c', line):
print "it's a c"
Which seems quite readable to me. The point of the "and if" is to
reduce indentation - that's all.
-----Original Message-----
From: sk...@calendar.com [mailto:sk...@calendar.com]
Sent: Wednesday, January 06, 1999 9:29 AM
To: pytho...@cwi.nl
Subject: Re: No Assignment in Conditional
"Evan Simpson" <ev...@tokenexchange.com> wrote:
> m = re.search('a', line)
> if m:
> print "it's an a"
> else:
> m = re.search('b', line)
> and if m:
> print "it's a b"
> else:
> m = re.search('c', line)
> and if m:
> print "it's a c"
> else:
> # etc
Other than saving a couple redundant tests, how is the above different
(or
more readable) than
m = re.search('a', line)
if m:
print "it's an a"
else:
m = re.search('b', line)
if m:
print "it's a b"
else:
m = re.search('c', line)
if m:
print "it's a c"
Evan Simpson
<61zp7wg...@anthem.cnri.reston.va.us>...
>
>The notion of `and while' isn't bad but I'll propose using different
>existing keywords: `continue if'. It reads better to me and combines
>notions of both constructs it would be used in.
I like it! I hope Guido does too.
[Usage in beaten-to-death line and match examples snipped]
>
>Better, but still not wonderful. Tim's right, if you just had return
>value assignments in the test, a lot of things would be much clearer.
See my Pita class in, well, somewhere in this vast tangled thread. Frankly
I'm getting as tired as I suspect Tim is of seeing these two particular
examples <wink>. That motivated me to do a little visual search through the
standard Python libs to see what, if anything, could be found in *real,
working code* that might justify any of my jumping up and down. There were
quite a few places where a "continue if" on a while loop (often *not* a
"while 1:") would improve the look of the code IHNSHO, though I'm not going
to cite any. Marching if's, on the other hand, were scarce, and hardly ever
worth fiddling with.
As before, after much thrashing, I bow to Guido's superior wisdom <wink>.
I've also realized that many genuinely bothersome marching-ifs could be cut
down like this:
if a():
b()
else:
c()
if d():
e()
else:
f()
if g():
# etc
becomes the homely but not hideous C-"switch"-like:
while "testing":
if a():
b()
break
c()
if d():
e()
break
f()
if g()
# etc
break # done testing
Mmmm... loop abuse
Evan Simpson
Evan Simpson
>> repeat "outer":
>
>loop "outer" or loop outer would indicate naming a loop. repeat
>"outer" seems like repeating a string... :)
Agreed :)
>> # stuff
>> repeat while test1:
>
>Why not just while test1?
So that it is syntactically regular, and distinguishable from the start of a
new loop at the same level. This is a kitchen-sink-included loop syntax,
which starts with:
loop ["<name>"] [while <expr>] [until <expr>] :
and can have sub-branches like "while <expr>:" and "until <expr>:".
>> until test4:: # double colon is synonym for "pass" body.
>
>What does this mean?
As long as I'm tossing around imaginary syntax, I though I'd throw in
another way of spelling an empty suite. In NotPython you can write:
try:
#code
except::
instead of
try:
#code
except: pass
How's that for gratuitous? <wink>
I've noticed a definite analogy between my attraction to this sort of syntax
nitpicking and the practice known as MacDinking. This is the syndrome where
a Macintosh (or Win32) user spends all day fooling around with icons,
sounds, and wallpapers, and never gets any real work done. In both cases,
the problem arises from great appreciation of and affection for the subject
of the twiddling, combined with a desire to have everthing "just so".
Perhaps someday I'll find the cure :-)
Mmmm... PyDinking
Evan Simpson
sk...@calendar.com
David> With your code if the first search returned true then you would see:
David> it's a a
David> it's a b
David> it's a c
Oops... yup. That's what I get for quickly reading but not executing the
code.
Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
sk...@calendar.com | Musi-Cal: http://concerts.calendar.com/
518-372-5583
Gary Herron
>
> The notion of `and while' isn't bad but I'll propose using different
> existing keywords: `continue if'. It reads better to me and combines
> notions of both constructs it would be used in.
>
> line = fp.readline()
> continue if line:
> result = process(line)
> continue if result:
> print 'The result was:', result
A small nitpick: This would associate two quite different actions with
the `continue' keyword.
In your case, the remaining lines of the loop body would usually be
executed, whereas the already existing use of `continue' causes those
same lines to be skipped. Very confusing. (Consider that `continue if
cond:' and `if cond: continue' have almost opposite meanings.)
But how about using `break' instead of `continue'? Then `break if
cond:' means the same as `if cond: break'. Indeed, the only difference
between the two is a matter of indentation.
--
+-------------------+-----------------------------------+
| Dr. Gary Herron | E-mail: ghe...@aw.sgi.com |
| Alias | Wavefront | Snail-mail: Alias | Wavefront |
| 206-287-5616 | 1218 3rd Ave, Floor 8 |
| | Seattle WA 98101 |
+-------------------+-----------------------------------+
Barry A. Warsaw
>>>>> "BAW" == Barry A Warsaw <bwa...@cnri.reston.va.us> writes:
BAW> Save the additional keyword and just use `is'
| while line is f.readline():
| do_stuff()
Because, dude, that already has a meaning! Sheesh, these language
designer wannabes.
BAW> But I don't even mind := or even = if parens are required
| while line := f.readline():
| do_stuff()
| while (line = f.readline()):
| do_stuff()
Now you're talkin'!
-Barry (the other one)
Barry A. Warsaw
>>>>> "DS" == David Stidolph <stid...@origin.ea.com> writes:
DS> Which seems quite readable to me. The point of the "and if"
DS> is to reduce indentation - that's all.
And is fine, unless you want to use the MatchObject that's returned
inside the body of the conditional. You can't get to it.
-Barry
Barry A. Warsaw
>>>>> "ES" == Evan Simpson <ev...@tokenexchange.com> writes:
ES> Marching if's, on the other hand, were scarce, and hardly ever
ES> worth fiddling with.
I've come across the situation enough times to be bugged by it, but to
tell the true, I can usually short-circuit the cascade by judicious
use of `break's and `return's inside the bodies of the conditions.
-Barry
Evan Simpson
and "continue if ..." clauses without giving anyone a valid excuse to be
confused, since they need only read them "if"-first. I still have a warm
place in my heart for "and while ...", though, since it actually has a
semantic connection to the suite which follows it. That is, the suite
following "if", "elif", "while", or "and while" executes iff the condition
in the clauses is true. A "break if" or "continue if", on the other hand,
is meant to prevent entry into the code suite. Am I making sense?
Ah, well. I'll be pleased if any of the zillion variations spawned by this
thread sees the light of Guido.
Gary Herron wrote in message <3693DD19...@aw.sgi.com>...
>In your case, the remaining lines of the loop body would usually be
>executed, whereas the already existing use of `continue' causes those
>same lines to be skipped. Very confusing. (Consider that `continue if
>cond:' and `if cond: continue' have almost opposite meanings.)
>
>But how about using `break' instead of `continue'? Then `break if
>cond:' means the same as `if cond: break'. Indeed, the only difference
>between the two is a matter of indentation.
Mmmm... loop bodies
Evan Simpson