|
From: <mi...@st...> - 2002-06-05 13:56:17
|
Mauro Cicognini wrote: > I'd wish to bring to your attention a bizarre thing that I noticed > yesterday. > > The documentation, at chapter 1.1.5.1 "LDAP operations", in the > description of the result() method, states that > > [...] > The result() method returns a tuple of the form |(/result-type/, > /result-data/)|. > [...] > > Now, I found that this isn't always true in the current (2.0.0pre04) > implementation: in fact, when result() is called with the 'all' > parameter set to non-zero (which BTW is the default), it returns just > the /result-data/ part. You're absolutely right. > I'd like to point out again that calling result() with all=0 would > return a tuple as documented, instead. > Moreover, the 1.x version of PythonLDAP result() worked 'correctly', > i.e. exactly as documented in all cases. > > I think it's strange that nobody noticed this so far, 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. 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. Ciao, Michael. |