On Tue, 31 Jan 2012 15:09:34 -0700, Ian Kelly wrote:
> On Tue, Jan 31, 2012 at 2:07 PM, Prasad, Ramit
> wrote:
>>>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 lo
On 1 February 2012 09:02, Peter Otten <__pete...@web.de> wrote:
> Prasad, Ramit wrote:
> > Is that true even in the face of something like sys.exit()?
> > What happens if 1) sys.exit is called while in the same thread
> > 2) sys.exit is called from another thread but while this thread
> > is in co
On Tue, Jan 31, 2012 at 2:07 PM, Prasad, Ramit
wrote:
>>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.
Prasad, Ramit wrote:
>>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
>
>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
On Wednesday, January 11, 2012 11:20:19 AM UTC-6, Ian wrote:
>
> 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 wo
On Wed, Jan 11, 2012 at 8:45 AM, wrote:
> However, then I read the following paragraph from PEP-343:
>
> Note that we're not guaranteeing that the finally-clause is
> executed immediately after the generator object becomes unused,
> even though this is how it will work in CPython. This
On 1/11/12 3:45 PM, joha...@gmail.com wrote:
I'm trying to write a context manager to handle database connections, under the
principle that I should not rely on CPython's reference-counting semantics to
clean up scarce resources, like connections.
I wrote:
@contexlib.contextmanager
def ensure
On 2012-01-11, joha...@gmail.com wrote:
> That suggests that I cannot rely on the
> contextlib.contextmanager decorator to ensure that the
> connection is closed and would have to write my own object with
> __enter__ and __exit__ methods to guarantee this.
contextmanager wraps your generator in a
I'm trying to write a context manager to handle database connections, under the
principle that I should not rely on CPython's reference-counting semantics to
clean up scarce resources, like connections.
I wrote:
@contexlib.contextmanager
def ensure_connection(con=None):
con_created = False
10 matches
Mail list logo
