Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAMZYqRQR0VFweQgN8jb3wkx-opabvVQJy5zRtQQrv7tnnzivwA@mail.gmail.com>
References: <jkda88$mrk$1@reader1.panix.com> <CAMZYqRQR0VFweQgN8jb3wkx-opabvVQJy5zRtQQrv7tnnzivwA@mail.gmail.com>
From: Chris Kaynor <ckaynor@zindagigames.com>
Date: Wed, 21 Mar 2012 13:54:13 -0700
Subject: Re: Best way to disconnect from ldap?
To: Chris Rebert <clp2@rebertia.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org, John Gordon <gordon@panix.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.875.1332363276.3037.python-list@python.org>
Lines: 128
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:22003

On Wed, Mar 21, 2012 at 1:34 PM, Chris Rebert <clp2@rebertia.com> wrote:
>
> On Wed, Mar 21, 2012 at 12:30 PM, John Gordon <gordon@panix.com> wrote:
> > I'm writing an application that interacts with ldap, and I'm looking
> > for advice on how to handle the connection. =A0Specifically, how to
> > close the ldap connection when the application is done.
> >
> > I wrote a class to wrap an LDAP connection, similar to this:
> >
> > =A0 =A0import ldap
> > =A0 =A0import ConfigParser
> >
> > =A0 =A0class MyLDAPWrapper(object):
> >
> > =A0 =A0 =A0 =A0def __init__(self):
> >
> > =A0 =A0 =A0 =A0 =A0 =A0config =3D ConfigParser.SafeConfigParser()
> > =A0 =A0 =A0 =A0 =A0 =A0config.read('sample.conf')
> >
> > =A0 =A0 =A0 =A0 =A0 =A0uri =3D config.get('LDAP', 'uri')
> > =A0 =A0 =A0 =A0 =A0 =A0user =3D config.get('LDAP', 'user')
> > =A0 =A0 =A0 =A0 =A0 =A0password =3D config.get('LDAP', 'password')
> >
> > =A0 =A0 =A0 =A0 =A0 =A0self.ldapClient =3D ldap.initialize(uri)
> > =A0 =A0 =A0 =A0 =A0 =A0self.ldapClient.simple_bind_s(user, password)
> >
> > My question is this: what is the best way to ensure the ldap connection
> > gets closed when it should? =A0I could write an explicit close() method=
,
> > but that seems a bit messy; there would end up being lots of calls to
> > close() scattered around in my code (primarily inside exception handler=
s.)
> >
> > Or I could write a __del__ method:
> >
> > =A0 =A0 =A0 =A0def __del__(self):
> > =A0 =A0 =A0 =A0 =A0 =A0self.ldapClient.unbind_s()
> >
> > This seems like a much cleaner solution, as I don't ever have to worry
> > about closing the connection; it gets done automatically.
>
> Yes, but not necessarily in a timely manner. Since its uses reference
> counting, CPython /just so happens/ to finalize
> non-cyclically-referenced objects promptly when they go out of scope,
> but Python-the-language makes no such guarantee, and indeed some of
> the other Python implementations explicitly disclaim that there may be
> a significant delay before finalization is performed.
>
> > I haven't ever used __del__ before. =A0Are there any 'gotchas' I need t=
o
> > worry about?
>
> In addition to the aforementioned problem regarding portability to
> other Python implementations, see also the Warning box under:
> http://docs.python.org/reference/datamodel.html#object.__del__
>
> I concur with J.'s context manager suggestion.

Personally, I would combine both methods (and maybe throw in a close
option as well). The standard interface would be to use the with
context, however in cases where that is not possible, an explicit
close is useful, and just in-case that is forgotten or missed, the
__del__ is there as a final backup.

The main case that context managers fail is when you need to break the
creation and teardown into separate methods, such as when writing a
more complex context manager.

As Chris Rebert pointed out, there is no guarantee as to when the
__del__ method is called. CPython will generally call it immediately,
however if there are reference cycles it may never call it:

class O(object):
    def __del__(self):
            print 'del'

a =3D O()
b =3D O()
a.obj =3D b
b.obj =3D a
del a
del b # After this, all references should be gone. Netiher a nor b are
accessable anymore, right?
# Yet del was never printed. Maybe a full garbage collection will help?
import gc
gc.collect()
# Nope...



Also, if the object exists and an exception is thrown, the object may
be held onto for extended periods of time, or may never get cleaned
up. A quick example of this issue:

>>> class O(object):
...     def __del__(self):
...             print 'del'
...
>>> def F():
...     o =3D O()
...     raise RuntimeError()
...
>>> F() # o is not garbage collected as sys.exc_info holds a reference to i=
t still in the traceback object.
RuntimeError
Traceback (most recent call last):
  File "<stdin-inspect>", line 1, in <module>
  File "<stdin-inspect>", line 3, in F
RuntimeError
>>> raise ValueError() # When another exception got thrown, it will get cle=
aned up....
del
ValueError
Traceback (most recent call last):
  File "<stdin-inspect>", line 1, in <module>
ValueError

In any case, it still makes a decent fall-back in case the user of
your code fails to properly clean-up. It will cover many of the common
cases, though you do need to be careful to never get into a reference
cycle if you have __del__ methods, or you get memory leaks.

>
>
> Cheers,
> Chris
> --
> http://mail.python.org/mailman/listinfo/python-list