Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #22003

Re: Best way to disconnect from ldap?

Show key headers only | View raw

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.  Specifically, how to
> > close the ldap connection when the application is done.
> >
> > I wrote a class to wrap an LDAP connection, similar to this:
> >
> >    import ldap
> >    import ConfigParser
> >
> >    class MyLDAPWrapper(object):
> >
> >        def __init__(self):
> >
> >            config = ConfigParser.SafeConfigParser()
> >            config.read('sample.conf')
> >
> >            uri = config.get('LDAP', 'uri')
> >            user = config.get('LDAP', 'user')
> >            password = config.get('LDAP', 'password')
> >
> >            self.ldapClient = ldap.initialize(uri)
> >            self.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?  I 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 handlers.)
> >
> > Or I could write a __del__ method:
> >
> >        def __del__(self):
> >            self.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.  Are there any 'gotchas' I need to
> > 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 = O()
b = O()
a.obj = b
b.obj = 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 = O()
...     raise RuntimeError()
...
>>> F() # o is not garbage collected as sys.exc_info holds a reference to it 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 cleaned 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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Best way to disconnect from ldap? John Gordon <gordon@panix.com> - 2012-03-21 19:30 +0000
  Re: Best way to disconnect from ldap? "J. Cliff Dyer" <jcd@sdf.lonestar.org> - 2012-03-21 16:21 -0400
  Re: Best way to disconnect from ldap? Chris Rebert <clp2@rebertia.com> - 2012-03-21 13:34 -0700
  Re: Best way to disconnect from ldap? Chris Kaynor <ckaynor@zindagigames.com> - 2012-03-21 13:54 -0700
  Re: Best way to disconnect from ldap? Tycho Andersen <tycho@tycho.ws> - 2012-03-22 08:14 -0500
    Re: Best way to disconnect from ldap? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 17:26 +0000
      Re: Best way to disconnect from ldap? Tim Chase <python.list@tim.thechases.com> - 2012-03-22 12:54 -0500
      Re: Best way to disconnect from ldap? Terry Reedy <tjreedy@udel.edu> - 2012-03-22 15:27 -0400
      Re: Best way to disconnect from ldap? Tycho Andersen <tycho@tycho.ws> - 2012-03-22 16:02 -0500
  Re: Best way to disconnect from ldap? Chris Rebert <clp2@rebertia.com> - 2012-03-22 06:27 -0700
  Re: Best way to disconnect from ldap? Tycho Andersen <tycho@tycho.ws> - 2012-03-22 09:00 -0500
  Re: Best way to disconnect from ldap? John Gordon <gordon@panix.com> - 2012-04-05 18:38 +0000
    Re: Best way to disconnect from ldap? Michael Ströder <michael@stroeder.com> - 2012-04-05 20:56 +0200

csiph-web