John Gordon wrote:
> class ldap.LDAPObject
> Instances of LDAPObject are returned by initialize() and open()
> (deprecated). The connection is automatically unbound and closed
> when the LDAP object is deleted.
>
> So, given that, do I need to do anything at all?
Hmm,
In John Gordon writes:
> 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:
> impor
On Thu, Mar 22, 2012 at 05:26:11PM +, Steven D'Aprano wrote:
> On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:
>
> > I've had similar experiences. In fact, in light of all this - why does
> > __del__ exist at all? Novice python users may (reasonably) assume it
> > behaves similarly t
On 3/22/2012 1:54 PM, Tim Chase wrote:
On 03/22/12 12:26, Steven D'Aprano wrote:
On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:
Given that you can't trust __del__, is there a legitimate
use case for it?
It is part of original or early Python and pretty well superceded by
cyclic gc
On 03/22/12 12:26, Steven D'Aprano wrote:
On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:
Given that you can't trust __del__, is there a legitimate
use case for it?
I've never found the need to write one.
I've found the need to write them...then been frustrated by
things falling o
On Thu, 22 Mar 2012 08:14:47 -0500, Tycho Andersen wrote:
> I've had similar experiences. In fact, in light of all this - why does
> __del__ exist at all? Novice python users may (reasonably) assume it
> behaves similarly to a C++ destructor (even though the docs warn
> otherwise).
What makes you
On Thu, Mar 22, 2012 at 06:27:45AM -0700, Chris Rebert wrote:
> On Thu, Mar 22, 2012 at 6:14 AM, Tycho Andersen wrote:
> > On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
> >> On 03/21/12 15:54, Chris Kaynor wrote:
> >> >As Chris Rebert pointed out, there is no guarantee as to when the
On Thu, Mar 22, 2012 at 6:14 AM, Tycho Andersen wrote:
> On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
>> On 03/21/12 15:54, Chris Kaynor wrote:
>> >As Chris Rebert pointed out, there is no guarantee as to when the
>> >__del__ method is called. CPython will generally call it immediate
On Wed, Mar 21, 2012 at 04:49:54PM -0500, Tim Chase wrote:
> On 03/21/12 15:54, Chris Kaynor wrote:
> >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 cal
On 03/21/12 15:54, Chris Kaynor wrote:
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
And more maddeningly, modules/objects used/called from within
On Wed, Mar 21, 2012 at 1:34 PM, Chris Rebert wrote:
>
> On Wed, Mar 21, 2012 at 12:30 PM, John Gordon 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 appli
On Wed, Mar 21, 2012 at 12:30 PM, John Gordon 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,
Write a context manager.
Then you just do
with MyLDAPWrapper() as ldap
ldap.this()
ldap.that()
and when you leave the scope of the with statement, your ldap __exit__
method will get called regardless of how you left.
Cheers,
Cliff
On Wed, 2012-03-21 at 19:30 +, John Gordon 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
14 matches
Mail list logo