[Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body
Michael Foord
fuzzyman at voidspace.org.uk
Sun Mar 15 21:01:21 CET 2009
Martin v. Löwis wrote:
>> Note that using exceptions for control flow can be bad for other
>> implementations of Python. For example exceptions on the .NET framework
>> are very expensive.
>>>> Why do you say that? What specific implementation of .NET are you
> referring to? What do you mean by "very"?
>I'm talking about IronPython on the Microsoft .NET framework - although
it is likely that the same is true of IronPython on Mono.
On the .NET framework the setup for exception handling is virtually free
until an exception is raised. Once an exception is raised it takes a lot
longer (expensive in time). This means that in IronPython exception
handling code (try... except and try... finally blocks) are much faster
than CPython if no exception is raised - but much more expensive if an
exception is raised.
You can see this in a comparison of IronPython 2 and Python 2.5 running
PyBench:
http://ironpython.codeplex.com/Wiki/View.aspx?title=IP201VsCPy25Perf
TryExcept: 26ms 888ms -97.1% 63ms 890ms -92.9%
TryRaiseExcept: 58234ms 1286ms +4428.6% 58474ms
1298ms +4404.6%
>> Isn't it better practise for exceptions to be used for exceptional
>> circumstances rather than for control flow?
>>>> This is an ongoing debate (in Python, and outside). I'm in the camp
> that says that exceptions are a control flow mechanism just like
> loops, conditionals, and recursion. With exceptions, you get essentially
> multiple alternative outcomes of a function call, rather than just a
> single result. In principle, it would be possible to eliminate the
> return statement altogether, but it is useful syntactic sugar.
>
Using exceptions for control flow is akin to goto. Sometimes useful but
a dubious practise. :-)
Michael
> Regards,
> Martin
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
More information about the Python-Dev
mailing list