[python-ldap] One vote for 3.x

Michael Ströder michael at stroeder.com
Tue Nov 29 17:49:08 CET 2011

Ilya Etingof wrote:
> Yes, pyasn1 is slow compared to C implementations. Off the top of my head,
> my estimation is that pure encoding/decoding operations are 5-10 times slower
> with pyasn1.

Like other modules you could try to rewrite the pure encoding/decoding
operations into a C module which is optionally imported (like StringIO vs.
cStringIO). But sure this will a lot of work. Sorry, I can't help with that
since I'm not a C programmer.

Anyway the whole SASL and SSL/TLS stuff will be a lot of work. Or one would
have to wrap cyrus-sasl libs and try to use a good crypto module.

All in all this is much effort. Given the experience with contributions so far
this is unlikely to happen any time soon. Continous support is needed not just
small patches. And as said in a former posting a couple of months ago:
Personally I don't have a need for Python 3.x at the moment.

Ciao, Michael.

>>> In the former case it might be easier and more robust to use pyasn1 than
>>> ctypes. BTW, pyasn1 seems to already be used in python-ldap for LDAP Controls.
>> I already considered that. But there are currently two reasons I'd stick to
>> using the OpenLDAP C client libs:
>> 1. Speed: It's definitely a difference decoding large search results compared
>> to occasionally en-/decoding some LDAP controls. But off course this needs
>> exact profiling.
>> 2. Functionality: It will be much work to implement everything, especially the
>> SASL stuff.

More information about the python-ldap mailing list