I'm coming from Tcl-world ...

[Andreas Leitgeb]

Now, that the try-continue-problem is sorted out ('twas a bug in 2.0),
I'll comment on it again:

Daniel Fackrell <unlearned at DELETETHIS.learn2think.org> wrote:
>>    for (<init>; <cond-a>; <incr>) {

> <init>
> while <cond-a>:
>     <incr>

There is already a difference here:
 In the original, the <incr>-part does *not* get evaluated *before*
 the body, but only at the end of the body (or through a "continue").

 It depends on the actual contents of <incr>, whether this can be
  compensated for in <init> or not. Sometimes it cannot, e.g. if it
  involves irreversible actions, such as next()ing an iterator ...
 (Of course <incr> would *not only* be an iterator.next() ! If it were,
  I would clearly use Python's "for" loop)

While the <init>-part is really just syntactic sugar, the <incr>-part
 can not trivially be emulated with a while.
If, additionally to the else:, python introduced an optional next:-branch
 (for while-loops) that would be evaluated just before re-evaluating the 
 condition, then this would fully satisfy any demand for a C-like for-loop.


I also want to re-comment on Cameron Hutchison's example that I had
refused for the same reason before:
"   i = 0
"   s = "*"
"   while i < 42:
"     try:
"       ...
"       if ...: continue
"       ...
"     finally:
"       i += 1
"       s += s 
This looks as if it came very near to the original, though
I can't verify it, (due to my old version 2.0 here) but it
appears as if at least other exceptions raised in the "..."-parts 
would be caught away from later handling.

Does "try" really catch "continue"s ?
  Or is there some misunderstanding ?

-- 
Newsflash: Sproingy made it to the ground !
  read more ... <http://avl.enemy.org/sproingy/>