Bug#750396: ITP: python-ldap3 -- A strictly RFC 4511 conforming LDAP V3 pure Python client

On 5 June 2014 01:02, Julien Cristau <julien.cristau@logilab.fr> wrote:

> This library has the advantage that it is pure Python code, I believe
> this means it doesn't require the C ldap library.
>

Whether that's an advantage is kind of disputable.

True.

The main advantage is that it is python3 compatible.

Still evaluating if it meets my needs though, maybe I was premature with the upload to incoming :-)

So far, my current progress, I have found (disclaimer: this is still early days, I might have some of this wrong):

* Connection process is different (I expected that).

* Unlike python-ldap, should support reconnecting automatically if connection dies. In practise this didn't work so well. I have a upstream ticket on this, haven't read the response yet. https://www.assembla.com/spaces/python3-ldap/support/tickets/21

* Search takes parameters in different order. Has a paged_size parameter, which looks interesting.

* Result returns results as { 'dn': dn, 'attributes': attributes } dictionary instead of (dn, attributes) tuple.

* Add/modify take a modlist parameter which is a dictionary, not a list.

* Different names, e.g. MODIFY_* instead of MOD_*.

* Documentation is ok, not excellent.

* Doesn't have anything similar to ldap.modlist, ldap.dn or ldap.filter modules. Which I use extensively. Most of these are in pure python and can be copied. ldap.dn.str2dn() looks like the exception, if I understand this correctly, it is native C code. ldap.modlist needs changes, due to different format required.

* Response to my ticket was rather prompt, however creating a ticket on www.assembla.com was a bit of a pain (website wanted me to create a 25 day free of charge project first).

* My current code creates an object, updates an attribute on that object, reads it back, and gets an empty object with no attributes. Still need to find out what is going on here. Might be my fault. It does appear my code is doing the right thing though.

The different modlist is perhaps worth explaining in detail, e.g. for modify, compare python-ldap syntax:

[(MOD_DELETE, 'sn', None), (MOD_ADD, 'sn', ['hello'])]

with python3-ldap syntax:

{'sn': (MODIFY_REPLACE, ['hello'])}

While it is simpler, it only allows one operation per attribute, so I have to use REPLACE. Which is probably more efficient anyway. This is perhaps the biggest change to my code base. In fact, possibly I should be using MODIFY_REPLACE more often, would mean I don't have to keep track of the current state of the attribute.

The documentation suggests that each dictionary value is a list of tuples, that doesn't match the code however.

Some sort of wrapper might be possible, and might actually be the best way to preserve compatibility between the two libraries. So far trying to avoid that however.

> I am considering naming the source python-ldap3, which is different from
> the upstream name, as it works with both python 2 and python 3, and it
> supplies the ldap3 module, not the ldap module. So it shouldn't conflict
> with the existing python-ldap package. If I know what I am doing, it
> will provide the python-ldap3 and python3-ldap binary packages.
>

Shouldn't that be python3-ldap3?

Yes, typo. Thanks. I got this right in the package I uploaded to incoming.

--
Brian May <bam@debian.org>