Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!cs.uu.nl!news.stack.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <10841855.1646.1326296715536.JavaMail.geo-discussion-forums@yqiz15>
References: <10841855.1646.1326296715536.JavaMail.geo-discussion-forums@yqiz15>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Wed, 11 Jan 2012 10:20:19 -0700
Subject: Re: contextlib.contextmanager and try/finally
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4658.1326302452.27778.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:18839

On Wed, Jan 11, 2012 at 8:45 AM,  <johannh@gmail.com> wrote:
> However, then I read the following paragraph from PEP-343:
>
> =A0 =A0Note that we're not guaranteeing that the finally-clause is
> =A0 =A0executed immediately after the generator object becomes unused,
> =A0 =A0even though this is how it will work in CPython. =A0This is simila=
r
> =A0 =A0to auto-closing files: while a reference-counting implementation
> =A0 =A0like CPython deallocates an object as soon as the last reference
> =A0 =A0to it goes away, implementations that use other GC algorithms do
> =A0 =A0not make the same guarantee. =A0This applies to Jython, IronPython=
,
> =A0 =A0and probably to Python running on Parrot.
>
> That suggests that I cannot rely on the contextlib.contextmanager decorat=
or to ensure that the connection is closed and would have to write my own o=
bject with __enter__ and __exit__ methods to guarantee this.
>
> Is this understanding accurate? =A0If so, could someone illustrate why th=
is is so?

First, this is just a timing issue.  There is no guarantee that the
finally clause will be executed immediately, but it is guaranteed to
be executed at some point.  In the other implementations, it would
happen whenever the GC algorithm runs.

Second, I believe that passage is not referring to the contextmanager
decorator specifically, but more generally to the changes that were
made to allow generators to yield from within a try-finally construct
(previously this would have been illegal syntax, since there was no
way to guarantee the finally block would be performed).

Like Neil mentioned, a contextmanager generator is wrapped with an
__exit__ method that is guaranteed to be called and that explicitly
resumes or closes the generator.  So as long as your contextmanager
generator is properly written (i.e. it yields exactly once), the
finally block will execute in a timely fashion.