[python3-ldap] Feedback on aspects of python3-ldap's API

python3ldap python3ldap at gmail.com
Tue Sep 23 08:55:21 CEST 2014


Hi Florian,
thanks for your message. I've crafted the API upon the official latest
LDAP specification (RFC 4510 and other). Each LDAP operation returns a
result code and an optional "payload". The "search" operation is not
different from the other operations, so when you invoke it you get
back a boolean that specify if the operation itself (regarding to the
protocol) was succesful. The result and the "payload" are too
information-rich  to be returned as a simple value (or tuple). So I
give them back as dictionaries (after decoding and  formatting as
required by the protocol) in the connection.result and
connection.response attributes.With this approach you can have the
complete control on what the LDAP server is returning (referral
handling is a good example of where this approach is helpful) and can
easily investigate any problem you could have. Furthermore having
decoupled the result and payload from the operation is helpful because
you can "plug" different "connection strategies" and they work all the
same. For example you can have the "reusable" strategy (a multiple
connection strategy to multiple servers) and keep the code almost
equal to the synchronous strategy. Even with asynchronous strategies
you get back the same result and response dictionaries with a inquiry
method of the connection itself.

Anyway there are some convenience functions in the
ldap3.extend.standard namespace that act as you intend. In the case of
 "paged" searches you can get the result back directly in the search
operation that act as a generator (or an accumulator). For example you
can have:

# simple paged search with generator - useful when returning a big dataset
for response in self.connection.extend.standard.paged_search('o=test',
'(cn=*)'):
            do_whatever_with(response)

or:
# simple paged search with accumulator - the paged search is executed
and accumulated in the result
responses = self.connection.extend.standard.paged_search('o=test',
'(cn=*)', generator=False)


Regarding the connection context manager there is no magic at all in
it. As stated in the docs the connection retains the status it had
before entering the context. This has been done because it's quite
expensive to bind a connection each time you get in the context, so
the connection is not destroyed when exiting it. Furthermore if you
use "lazy" connections (that bind only if there is some real operation
to perform) you gain a speed boost in long standing routines (I work
mainly on identity management systems and this has proven useful).

Feel free to give back suggestion and criticism on this mailing list.

Bye,
Giovanni


2014-09-22 19:15 GMT+02:00 Florian Friesdorf <flo at chaoflow.net>:
>
> Hi Giovanni,
>
> On community.plone.org[1] you are asking what we consider confusing
> about python3-ldap's API. I hope it is in your interest that I post this
> feedback here to the python3-ldap list. To the other aspects of your
> posting I will reply on community.plone.org
>
> [1] https://community.plone.org/t/ldap-status-quo-and-where-to-go-from-here/285
>
> On Sun, Sep 21 2014, cannata_g wrote:
>> Hello everybody,
>> I'm the author of python3-ldap. I read in your message that you think
>> that the python3-ldap API is "confusing". I'd like to know what you
>> mean by that, are you referring to the documentation (still not
>> completed) or to the API itself?.
>
> The opinion that python3-ldap's API is confusing to us, was formed after
> a brief look at the quick tour[2]:
>
> [2] http://pythonhosted.org/python3-ldap/quicktour.html
>
> To perform a search, python3-ldap uses a connection object on which a
> search method is called with the search parameters. The result is not
> returned but instead there are .result and .response attributes on the
> connection.
>
> When using a connection as context-manager, the connection lives on
> after leaving the context. Within the context the binding to the ldap
> server is magically changed.
>
> Both these things we consider rather untypical for pythonic APIs.
>
> regards
> Marko and Florian
> --
> Florian Friesdorf <flo at chaoflow.net>
>   GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
> Jabber/XMPP: flo at chaoflow.net
> IRC: chaoflow on freenode,ircnet,blafasel,OFTC
>
> _______________________________________________
> python3-ldap mailing list
> python3-ldap at python.org
> https://mail.python.org/mailman/listinfo/python3-ldap
>


More information about the python3-ldap mailing list