Prev: OptParse and Constant values
Next: Inserting/Deleting newline(s) in very large text files
From: wheres pythonmonks on 12 Aug 2010 14:54
On Thu, Aug 12, 2010 at 2:42 PM, MRAB <python(a)mrabarnett.plus.com> wrote:
> wheres pythonmonks wrote:
>>
>> Hi!
>>
>> I have on a few occasions now wanted to have inline-exception
>> handling, like the inline if/else operator.
>>
>> For example,
>>
>> The following might raise ZeroDivisionError:
>>
>> f = n / d
>>
>> So, I can look before I leap (which is okay):
>>
>> f = float("nan") if d == 0 else n/d;
>>
>> But, what I'd like to be able to write is:
>>
>> f = n / d except float("nan");
>>
>> Which I find much more appealing than:
>>
>> try:
>>   f = n / d
>> except:
>>   f = float("nan")
>>
>> (Obviously, I am thinking about more complicated functions than "n/d"
>> -- but this works as an example.)
>>
>> Thoughts?
>>
> Discussed a year ago:
>
> [Python-Dev] (try-except) conditional expression similar to (if-else)
> conditional (PEP 308)
>
> http://code.activestate.com/lists/python-dev/90256/
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>


http://code.activestate.com/lists/python-dev/90256/

Nice -- excellent discussion and what I was looking for. I am
guessing that no implementation materialized.
From: Thomas Jollans on 12 Aug 2010 14:57
On Thursday 12 August 2010, it occurred to wheres pythonmonks to exclaim:
> [I just hate function call overhead for this.]

I think you've got your priorities wrong. If you want to avoid unnecessary
overhead, avoid exceptions more than functions.

From: wheres pythonmonks on 12 Aug 2010 16:18
On Thu, Aug 12, 2010 at 2:57 PM, Thomas Jollans <thomas(a)jollybox.de> wrote:
> On Thursday 12 August 2010, it occurred to wheres pythonmonks to exclaim:
>> [I just hate function call overhead for this.]
>
> I think you've got your priorities wrong. If you want to avoid unnecessary
> overhead, avoid exceptions more than functions.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Well I suppose it matters depending on the nature of the data you are
looking at... But small function calls tend to be the death of
interpreted languages...

>>> timeit.timeit("""
def f(y,i):
try:
return(y/(i%10))
except:
return(float("nan"))

for i in range(100):
x = f(7,i)

""")
56.362180419240985

>>> timeit.timeit("""
for i in range(100):
try:
x = 7 / (i % 10)
except:
x = float("nan")
""")
34.588313601484742
>>>
From: Carey Tilden on 12 Aug 2010 17:46
On Thu, Aug 12, 2010 at 1:18 PM, wheres pythonmonks
<wherespythonmonks(a)gmail.com> wrote:

> Well I suppose it matters depending on the nature of the data you are
> looking at...  But small function calls tend to be the death of interpreted
> languages...

I would be interested to see a real application that had performance
negatively impacted by function call overhead. Sure, it's easy to
measure in micro benchmarks, but what about profiling a real
application?

Carey
From: Steven D'Aprano on 13 Aug 2010 01:40
On Thu, 12 Aug 2010 20:08:01 +0200, Thomas Jollans wrote:
[...]
> Besides, more often than not, you want to have a finally clause around
> when you're dealing with exceptions.

Oh I don't know about that. Doing a quick and totally unscientific survey
of my own code, I find that try...except with no finally outnumbers
try...finally by about 10 to 1.

In any case, any syntax for inline exception handling should be kept nice
and lightweight. It shouldn't try to duplicate all the functionality of
try...except...else...finally blocks.



--
Steven
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: OptParse and Constant values
Next: Inserting/Deleting newline(s) in very large text files