[Python-ideas] [Fwd: Re: exception based conditional expression, similar to if-else conditional expression]

[Jeff McAninch]

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 
while loops.

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
Physicist, X-2-IFD
Los Alamos National Laboratory
Phone: 505-667-0374
Email: mcaninch at lanl.gov
==========================