about how python-ldap is trade safe.

[Michael Ströder]

Alain,

thanks for reviewing the code of ldapobject.py thoroughly.

Alain Spineux wrote:
> 
> Finally I found every object contains its own lock ! (if the used ldap
> library is reentrant)
> and their was no bottleneck. I was happy :-)

Yes, if linked against libldap_r (check your setup.cfg).

> But _ldap_function_call is still used to call _ldap.initialize at some place
> 
> [root at fc6-eg ldap]# grep _ldap.initialize *.py
> ldapobject.py:    self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:        self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:      self._l = self._ldap_call(_ldap.initialize,self._uri)
> 
> why not to replace the use of _ldap_function_call by the more
> appropriate _ldap_call, already used in the last line !

Hmm, IMO it's the other way round. I'd rather consider it a stupid
copy&paste bug that self._ldap_call() is invoked for wrapping
_ldap.initialize() within SmartLDAPObject. I've fixed and committed this.

Please review OpenLDAP's ldap.h. You'll find that ldap_initialize() is a
completely different thing.

> And that way
> debugging will provide and uri for initialise call!

ldap.functions._ldap_function_call() also can produce debug output.

But you have to explicitly set module vars ldap._trace_level,
ldap._trace_file and ldap._trace_stack_limit to enable it. The latter
two being optional off course.

Ciao, Michael.