Strange behavior in Python-LDAP 2.0.0pre04

Mauro Cicognini mcicogni at siosistemi.it
Wed Jun 5 16:14:50 CEST 2002


Michael Ströder wrote:

> I noticed it and wanted to change it long ago but did not discuss that 
> here. Thanks for reminding me about this open issue. I guess others 
> didn't notice it since nobody calls result() with all=1. Instead 
> others are using e.g. search_s() instead I guess.

This is a welcome reassurance. I'm not going crazy then ;-)

> I've implemented LDAPObject.result() in ldap.ldapobject which is 
> mainly a wrapper around the internal result() method. The original 
> result() is never called with all=1. Instead LDAPObject.result() 
> handles that internally (also the timeout parameter). The goal was to 
> turn all sync API calls into async API calls to avoid having to use 
> the module-wide lock too long. (OpenLDAP 2 libs are not thread-safe.) 
> The code is somewhat clunky and everybody is invited to dig into that.

I have always used the async versions of the calls for the same reason. 
In fact I've never resorted to calling result() with all=0 so far, just 
because my result sets are (usually) on the smaller side.

So it's OK if I change the result() implementation within ldapobject.py?
My idea would be to make result() always return what's expected in the 
docos, i.e. always a tuple, emulating the 1.x behavior (and avoiding the 
breakage in my existing code).

Suggestions, anyone?

Mauro

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20020605/554c614a/attachment.bin>


More information about the python-ldap mailing list