Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?
michael at stroeder.com
Thu Mar 11 08:57:58 CET 2004
David Leonard wrote:
> The reason for having l_ldap_result convert from int to string, was purely
> that it made the returned tuple easier to inspect visually.
I already dropped it. Bring your CVS dir in sync.
> You are right that removing the translation and changing the 'constants' to
> numbers would break anyone's code that used string literals.
Well, this seems a minor issue to me. I fixed mine. Using constants is also
more robust against typos.
> An alternate (and more high-level) approach would be to create a Result
> class, and have l_ldap_result return instances of Result (instead of a
> tuple). Using __getitem__ you could make it backward-compatible with the
> extant tuples. Also, using __repr__ you could have Result instances make
> sense when printed interactively.
I already thought about changing all this mess with l_ldap_result() and
define different classes for the result types. I could do lots of these
things in ldap.ldapobject.LDAPObject wrapper class but maintaining the C
code is a major PITA for me.
We should strip down l_ldap_result() to be a really dumb wrapper around
OpenLDAP's ldap_result() and do the backward-compatible rest in
> you could change all the RES_ constants to be
> integers and that would much better match ldap.h.
Already done. Since the C code is still a big mystery to me and it highly
depends on API decisions of the OpenLDAP folks I'm generally trying to make
it as lean as possible stripping everything away and eventually reimplement
it in the Python wrapper modules.
More information about the python-ldap