[Python-ideas] [Fwd: Re: exception based conditional expression, similar to if-else conditional expression]
mcaninch at lanl.gov
Thu Aug 20 13:18:42 CEST 2009
Chris Rebert wrote:
> Yech. That doesn't look so great.
I agree about the parens, but thought I should put it out there. The
parens around the exception clauses should not be required, but should
be allowed to reduce ambiguity, In my own case, I would tend to use
continuation lines to make multi-exception expressions more readable.
> At any rate, I do seriously question the bang-for-the-buck of adding
> this construct. Yes, it makes such conversions shorter, but couldn't
> one just define a `float_or_nan` conversion function that defaults to
> NaN in case of error to essentially the same effect?
> I can see how the construct might help in comparatively
> quick-and-dirty scripts, but should Python actively encourage
> comparatively cavalier error-handling?
One of the surprising things about Python is the impressive performance
that can be achieved, even though it is an interpreted langauge. In my
experience, this is one of the aspects of Python that sets it apart from
other interpreted environments, and why I can apply Python to heavy duty
scientific computing in the same environment where I pop up a gui or
parse a text file.
This performance is achieved as one increases the ratio of work done in
compiled code, to the amount of work being done by the interpreter.
Hence, list comprehensions and iterator expressions, in place of for and
The bang-for-the-buck in the exception expression is in performance.
This is not in any way just a quick-and-dirty issue. It's exactly the
same motivation as the if-else expression.
Please correct me if I am in error, but doesn't a call to a python
function (as opposed to a compiled C-function) substantially slow down a
list comprehension? (I will endeavor to generate a test case this
weekend and post the results, but this is consistent with everything
I've read about optimizing Python code.)
And remember, this is called "exception-handling" rather than
"error-handling" for a reason. In many practical cases, the exceptions
can be a significant, if not dominant, fraction of the executions of the
code. That, I thought, was the logic behind try:except in the first
place: treating exceptions as a natural part of the coding, rather than
a collection of special cases.
I see this as encouraging more robust, rather than more cavalier,
exception handling, and doing it in a more concise syntax (and I assert,
more efficient from a performance perspective -- I'll try to put this
assertion to a quantitative test this weekend.).
Jeffrey E. McAninch, PhD
Los Alamos National Laboratory
Email: mcaninch at lanl.gov
More information about the Python-ideas