About python 2.5 and its try statement.

[defcon8]

I can't remember the proposal number, but many of you reading will have
probably read the features that will be added to python 2.5. The actual
part I wanted to talk about was the finally part of try. Isn't it
totally defeating a compiler's job by executing the finally part even
if there is an error in the previous statements? Or have I understood
something wrong?

[Tim N. van der Leeuw]

Re: About python 2.5 and its try statement.

Hi,


defcon8 wrote:[color=blue]
> I can't remember the proposal number, but many of you reading will have
> probably read the features that will be added to python 2.5. The actual
> part I wanted to talk about was the finally part of try. Isn't it
> totally defeating a compiler's job by executing the finally part even
> if there is an error in the previous statements? Or have I understood
> something wrong?[/color]

try ... finally already exists in current python; what's new is that it
can be combined in 1 statement with try ... except ... finally.

No, this is not defeating a compilers job. It's very useful.

It defines an amount of cleanup that needs to happen no matter what,
exception or no exception. Example: closing an open file. You'll want
to close the file, whether after you done the job you intended to do,
or after an exception occurred while doing something.

So you put 'f.close()' in your finally - suite.

Another example of a useful 'finally' is logging function-exit -- not
the actual 'return' statement, but just a log-statement recording
function-exit.

(Putting a 'return' statement in a 'finally' suite is totally defeating
the point of exceptions that you want thrown to the caller, yes. So
don't put your 'return' statement there.)

Clearer?

Cheers,

--Tim

[Bruno Desthuilliers]

Re: About python 2.5 and its try statement.

defcon8 wrote:[color=blue]
> I can't remember the proposal number,[/color]

http://docs.python.org/dev/whatsnew/pep-341.html

but many of you reading will have[color=blue]
> probably read the features that will be added to python 2.5. The actual
> part I wanted to talk about was the finally part of try.[/color]

It has been here from the start (well, IIRC, it's since at least 1.5.2)
- the only limitation was that you couldn't use both 'except' and
'finally' in the same statement, so you had to wrap'em when needed.
[color=blue]
> Isn't it
> totally defeating a compiler's job by executing the finally part even
> if there is an error in the previous statements?[/color]

I don't see how this relates to the compiler. But anyway, the whole
point of the 'finally' clause is (and has ever been) to *ensure* this
block gets executed *whatever* happened. FWIW, the canonical use case is
resource aquisition/release.
[color=blue]
> Or have I understood
> something wrong?[/color]

Seems so - unless it's me misunderstading your question.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Fredrik Lundh]

Re: About python 2.5 and its try statement.

"defcon8" wrote:
[color=blue]
>I can't remember the proposal number, but many of you reading will have
> probably read the features that will be added to python 2.5. The actual
> part I wanted to talk about was the finally part of try. Isn't it
> totally defeating a compiler's job by executing the finally part even
> if there is an error in the previous statements? Or have I understood
> something wrong?[/color]

sounds like you're confusing compilation and execution, and compilation errors
(syntax errors) with runtime errors (exceptions).

try-finally is a runtime thing, not a compile time thing.

</F>