Strange behavior in Python-LDAP 2.0.0pre04
michael at stroeder.com
Wed Jun 5 16:24:28 CEST 2002
Mauro Cicognini wrote:
>> 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.
Just use the search_s() or search_st() methods which are solely
implemented in ldap.ldapobject.LDAPObject. I completely removed
them from the C module part.
Set trace_level=1 when calling ldap.initialize() to track all the
python-ldap API calls.
> 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).
You're welcome to dig into that and find the bug I've made. But
please keep in mind as requirement that the C implementation
should never be called with all=1.
Note that ldap.ldapobject.LDAPObject.*_s() and
ldap.ldapobject.LDAPObject.search_st() will also need some
tweaking after fixing the bug in ldap.ldapobject.LDAPObject.result().
More information about the python-ldap