By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,678 Members | 1,329 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,678 IT Pros & Developers. It's quick & easy.

Exceptions as a Control Structure

P: n/a
Hi all,

I am new to Python (I just finished Guido's tutorial).
I was very surprised to learn there that the StopIteration
is used to end for loops in a standard iterator setting.

I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.

What is the Python canon on this topic ? Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?

Regards,
Olivier.

Jul 18 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Olivier Parisy wrote:
I am new to Python (I just finished Guido's tutorial).
I was very surprised to learn there that the StopIteration
is used to end for loops in a standard iterator setting.

I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.
In Python, very little is frowned upon solely for efficiency
reasons. There are some examples, including using +=
repeatedly to grow a string, and some fields where efficiency
is of course critical, but in Python one almost always looks
for the most pragmatic approach (which is often the most
elegant, too, for some people's definition of elegant)
rather than obsessing about speed.
What is the Python canon on this topic ?
The only Python "canon" can be found by typing "import this"
at the interpreter prompt. ;-)
Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?


Catching an exception is considered a reasonable approach
to flow control for various problems. One, for example,
is in deeply nested loops, where rather than going out of
one's way to avoid exceptions in favour of a flag and lots
of awkward testing, one just raises a custom exception
(or perhaps a standard one) and catches it outside the
loops.

Exceptions are also used by some as a mechanism for
returning information from subroutines, though it's
very likely the information will still be considered
"exceptional" in some way (think of it as an out-of-band
mechanism for returning special info).

While some people object on stylistic grounds (or even
performance ones, in some cases) to such things, you
will likely find that exceptions are thrown around
by Python programmers more readily than you are used to.

Note also that in many cases other than algorithmic
complexity, what you have learned about efficiency in
C++ should be considered suspect info when it comes
to Python. Function calls, for example, are much more
expensive in Python than in C++ because of the time
required to set up the call frame. Exceptions, on the
other hand, are as I recall much more efficient.
Some Google Group searches in c.l.p would probably
lead to many past discussions of these things.

-Peter
Jul 18 '05 #2

P: n/a
In article <41***********************@news.free.fr>,
Olivier Parisy <ol************@free.fr> wrote:
Hi all,

I am new to Python (I just finished Guido's tutorial).
I was very surprised to learn there that the StopIteration
is used to end for loops in a standard iterator setting.

I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.

What is the Python canon on this topic ? Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?


Lots of things you do in C++ are frowned upon in Python. Lots of things
you do in Python are frowned upon in C++.

Specifically, exceptions in C++ are generally considered fairly
heavy-weight, but not so in Python. Here's another common python idiom
that uses exceptions in a way which would probably horrify most C++
people:

for key in sequence:
try:
foo = dictionary [key]
except KeyError
foo = "not found"

instead of:

for key in sequence:
if dictionary.has_key (key):
foo = dictionary [key]
else
foo = "not found"

If you're reasonably sure that most of the keys will be found in the
dictionary, it's probably faster to just try them all and handle the
occasional exception than to test each key to see if it exists.
Jul 18 '05 #3

P: n/a
Peter Hansen wrote:
In Python, very little is frowned upon solely for efficiency
reasons. There are some examples, including using +=
repeatedly to grow a string, and some fields where efficiency
is of course critical, but in Python one almost always looks
for the most pragmatic approach (which is often the most
elegant, too, for some people's definition of elegant)
rather than obsessing about speed.
I understand this. That's one of the reasons I am learning
Python (I am more interested in improving my development time
than my programs' execution time).

Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?

Catching an exception is considered a reasonable approach
to flow control for various problems. One, for example,
is in deeply nested loops, where rather than going out of
one's way to avoid exceptions in favour of a flag and lots
of awkward testing, one just raises a custom exception
(or perhaps a standard one) and catches it outside the
loops.


OK. Definitely not something I'd do in C++.
Exceptions are also used by some as a mechanism for
returning information from subroutines, though it's
very likely the information will still be considered
"exceptional" in some way (think of it as an out-of-band
mechanism for returning special info).
Do you have some example of this in the standard library ?
While some people object on stylistic grounds (or even
performance ones, in some cases) to such things, you
will likely find that exceptions are thrown around
by Python programmers more readily than you are used to.
That's what I wanted to know. OK.
Note also that in many cases other than algorithmic
complexity, what you have learned about efficiency in
C++ should be considered suspect info when it comes
to Python. Function calls, for example, are much more
expensive in Python than in C++ because of the time
required to set up the call frame. Exceptions, on the
other hand, are as I recall much more efficient.
So I suppose I just won't concern myself with efficiency
questions and concentrate on prope style, then.
Some Google Group searches in c.l.p would probably
lead to many past discussions of these things.


I must admit I probably didn't do my homework...
BTW, thanks for your reactivity !

Regards,
Olivier.

Jul 18 '05 #4

P: n/a
And don't forget about:

for key in sequence:
foo = dictionary.get(key, "not found")

:)

Chris

On Mon, 09 Aug 2004 09:16:28 -0400, Roy Smith <ro*@panix.com> wrote:
In article <41***********************@news.free.fr>,
Olivier Parisy <ol************@free.fr> wrote:
Hi all,

I am new to Python (I just finished Guido's tutorial).
I was very surprised to learn there that the StopIteration
is used to end for loops in a standard iterator setting.

I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.

What is the Python canon on this topic ? Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?


Lots of things you do in C++ are frowned upon in Python. Lots of things
you do in Python are frowned upon in C++.

Specifically, exceptions in C++ are generally considered fairly
heavy-weight, but not so in Python. Here's another common python idiom
that uses exceptions in a way which would probably horrify most C++
people:

for key in sequence:
try:
foo = dictionary [key]
except KeyError
foo = "not found"

instead of:

for key in sequence:
if dictionary.has_key (key):
foo = dictionary [key]
else
foo = "not found"

If you're reasonably sure that most of the keys will be found in the
dictionary, it's probably faster to just try them all and handle the
occasional exception than to test each key to see if it exists.
--
http://mail.python.org/mailman/listinfo/python-list

--
Still searching for an even prime > 2!
Jul 18 '05 #5

P: n/a
Roy Smith wrote:
Lots of things you do in C++ are frowned upon in Python. Lots of things
you do in Python are frowned upon in C++.
This is something I need to learn. I suppose there's not much written
information on this informal topic, and that I'll have to read some
source code... Any advice on cleanly written projects from that point
of view ?
Specifically, exceptions in C++ are generally considered fairly
heavy-weight, but not so in Python. Here's another common python idiom
that uses exceptions in a way which would probably horrify most C++
people:

for key in sequence:
try:
foo = dictionary [key]
except KeyError
foo = "not found"

instead of:

for key in sequence:
if dictionary.has_key (key):
foo = dictionary [key]
else
foo = "not found"


Hum, I stumbled on this FAQ a short time after I posted here, indeed :-)

Regards,
Olivier.

Jul 18 '05 #6

P: n/a
Olivier Parisy wrote:
Peter Hansen wrote:
Exceptions are also used by some as a mechanism for
returning information from subroutines, though it's
very likely the information will still be considered
"exceptional" in some way (think of it as an out-of-band
mechanism for returning special info).


Do you have some example of this in the standard library ?


It's easy to check for yourself, you have the source. ;-)

I searched for "(Exception" in the lib/*.py files, since
this code is likely to occur when someone subclasses the
top-level exception class.

There's an example similar to what I was describing in
inspect.py, using an EndOfBlock exception. The Queue
module has Full and Empty exceptions that are a good
example. By far the most occurrences of custom
exceptions are to define specialized ones denoting
error conditions, however. I suspect the usage I
described is more common outside the standard library,
in part because code where it would be useful is more
likely to occur in higher level code.

-Peter
Jul 18 '05 #7

P: n/a
> > Exceptions are also used by some as a mechanism for
returning information from subroutines, though it's
very likely the information will still be considered
"exceptional" in some way (think of it as an out-of-band
mechanism for returning special info).


Do you have some example of this in the standard library ?


pyparsing uses this technique to try various parse expressions - a raised
ParseException denotes that the attempted parsing pattern failed to match at
the current stream location.

In an earlier incarnation of this library, I implemented this by returning
True or False values to indicate successful matching, but when a False was
returned, I found I needed more information about why things were False.
The exception-based approach allows me to return a full exception, including
the match failure message and the location at which the failure occurred.

One optimization I have found w.r.t. exceptions is that, in pyparsing, a
given parsing expression always raises the almost the same exception, with
only the input location changing. I found a significant improvement by
pre-constructing the exception at grammar construction time, and then
raising a modified version at parse time. (Contrast with the dynamic
construction/garbage-collection of thousands of exception objects when
created and used only once.)

-- Paul
Jul 18 '05 #8

P: n/a
On Mon, 09 Aug 2004 15:01:38 +0200
Olivier Parisy <ol************@free.fr> wrote:
Hi all,

I am new to Python (I just finished Guido's tutorial).
I was very surprised to learn there that the StopIteration
is used to end for loops in a standard iterator setting.

I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.

What is the Python canon on this topic ? Are exceptions
considered as reasonable control structures, or is
StopIteration alone of its kind ?


Actually StopIteration is a semantic peer of the long standing
IndexError and KeyError exceptions used in sequences and dicts.

In general I think you will find python uses exceptions often for flow
control. The try: except: block is more or less free if no exception
actually occurs.

-Casey

Jul 18 '05 #9

P: n/a
In article <41***********************@news.free.fr> (Mon, 09 Aug 2004
15:01:38 +0200), Olivier Parisy wrote:
I come from C++, where the use of exceptions as control
structures is frowned upon for efficiency reasons.
In Bertrand Meyer's Eiffel, this is prohibited by the language design.
Exceptions wouldn't have been my choice for this kind of control, but Dr.
van Rossum is far more educated than I.
What is the Python canon on this topic ?
Exceptions are a primary control structure.
Are exceptions considered as reasonable control structures, or is
StopIteration alone of its kind ?


Yes. No.

--
"It's not like IBM can support Linux the way they support the mainframe
operating system. They don't write the code for it."
-- Steve Ballmer. http://news.com.com/2008-1082-998297.html. 25 Apr 2003

Jul 18 '05 #10

P: n/a
[Peter Hansen]
Exceptions are also used by some as a mechanism for
returning information from subroutines, though it's
very likely the information will still be considered
"exceptional" in some way (think of it as an out-of-band
mechanism for returning special info).
[Olivier Parisy] Do you have some example of this in the standard library ?
Not sure if this is what Peter had in mind, but grep for 'ValueError'.
[Peter] While some people object on stylistic grounds (or even
performance ones, in some cases) to such things, you
will likely find that exceptions are thrown around
by Python programmers more readily than you are used to.
[Olivier Parisy] That's what I wanted to know. OK.


Control-structure-y uses (esp. within a single function) are much
rarer than the ordinary use: a function signalling an exceptional
condition to its callers. This ordinary use is certainly used more
extensively in idiomatic Python code than is the case in many other
languagesa.

StopIteration is used a lot, I guess, but it's rare that you're
actually concious of that fact.
John
Jul 18 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.