control structures (was "Re: Sins")
skaller
skaller at maxtal.com.au
Sat Jan 8 09:50:34 EST 2000
Skip Montanaro wrote:
>
> Emile> Doesn't this do that now? or is there some objection to this usage?
>
> [ ... snip try/except used to implement state machine ... ]
>
> I find nothing wrong with it. Some people object to using try/except for
> anything but handling errors however.
My objection is twofold. First, the syntax is unweildy:
try:
for i in range(3):
if ... : raise X
except X:
requires at least one extra level of indentation.
[I'm interested in a 'generic' way to combine
python statements which avoids this (like 'elif' does)
Any ideas?]
My second objection is more serious:
try .. raise .. except is too dynamic (for this usage):
there is no way to match up the exceptions actually
thrown with the handlers.
The constructions under consideration
(variants on a construction proposed by Knuth)
would support compile time verification that
every loop exit had a corresponding handler
lexically following the loop.
In particular, 'falling through'
such a loop is impossible: all exits must be explicit.
Current looping constructions are so bad,
that the simplest of uses cannot be expressed
using them : searching a list for an element
cannot be written correctly:
for i in X:
if X[i]=e: goto Found
print "Not Found"
goto next
Found: ...
next
YUKKKKKK!!! There is no natural way to do this.
We fall through the loop on failure, instead
of success. (using a flag, or testing anything
afterwards, is not acceptable as a solution).
Using exceptions:
try:
for i in X:
if X[i]==e: raise Found
raise NotFound
except Found: ..
except NotFound: ..
is much cleaner, but exceptions are excessively
dynamic for what is essential a static control
flow problem. A solution will resemble the
above exception handling implementation .. but
with the matching up of exits and handlers enforced
at compile time.
--
John (Max) Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850
More information about the Python-list
mailing list